Вот, вы опять вместо ответа на вопрос, начинаете вилять словами.
Мне интересны различия, особенно, если они а) внятны и б) полезны.
Ваши термины не блещут ни тем, ни другим.
Если у нас есть кусок ткани синего цвета, то из свойств нам полезны будут размер, конкретный тон синего, тип ткани, форма… И лишь в некоем гипотетическом крайнем случае будет важно то, что все нити в этом куске синего цвета, и, о боже, любой фрагмент любой нити тоже синего цвета.
Но вопрос остаётся вез ответа — зачем делать этой крайний случай краеугольным?
Ответ на вопрос «как в ООП построена работа со множествами?» — никак. ООП не про это.
ООП, как и любая другая парадигма программирования, описывает методику моделирования абстракций. С точки зрения программирования, и интервал и множество — это в первую очередь абстракции. И любой нормальный программист смоделирует их так, как это будет удобно и полезно в рамках выбранной парадигмы.
ps
«Любой нормальный» — сильное утверждение, но это моё имхо.
А зачем нам договариваться об этом тезисе?
Вы очень хотите убедить всех присутствующих в важности такого разделения между объектом и множеством, но совсем не объясняете, зачем. Зачем вводить сложность там, где реальность моделируется более простыми средствами?
И почему это вдруг в ИС не моделируются интервалы?.. И чём принципиальная разница, с точки зрения программирования, утверждений "просто существовал указанный интервал" и "он существовал в любой интервал из указанного"?
В общем и целом — прописные истины… Хотя… К сожалению, не для всех :(
Логи, дэшборды, подсказки с коде — как по мне, так это индустриальный стандарт. Для всех, кто умеет думать наперёд, т.е. в курсе, что shit happens и всяко приятнее, когда разобраться, что к чему, можно быстро и безболезненно.
Вот только про пони всё-же перебор. Пот понадобится тебе сайт внутреннего мониторинга поднять, глядь в гит, а там Apple Dazzle погоняет Plumsweet и т.д… Мне всё же ближе нормальная доменная структура. Вариантов масса, но при единстве структуры, ориентироваться в Company/Infrastructure/Monitoring/Site сильно проще.
Бесполезно сравнивать IT с другими сферами деятельности.
Условно говоря, количество врачей/учителей/юристов/экономистов и т.д. примерно пропорционально количеству людей. В сферах же исследования и производства всё очень сильно зависит от горизонта.
Как только в какой-либо научной сфере появляются новые горизонты, образуется ниша, куда вливаются специалисты, и не важно, чем обусловлен тот горизонт — экономическими перспективами или теоретическими. Но, в первом случае там больше денег :), поэтому и специалистов там много и они не бедствуют.
Похожие дела с производством — пока очередной рынок сбыта не будет насыщен, зарплатам есть откуда браться. Но стоимость рабочей силы зависит от рынка низкоквалифицированных кадров, а стоимость управленцев определяется конкуренцией и сложностью задач. Обычно получается так, что зарплаты рабочих получают всплеск, заканчивающийся с насыщением рабочих мест, а у топов зарплаты растут, пока не кончается конкуренция.
IT-сфера имеет черты и научной деятельности и производственной. И горизонты пока только расширяются. Фокус в том, что IT проникает во все прочие сферы жизнедеятельности человечества. И границы этого проникновения не видны. Ясна только общая тенденция — всё, кроме творческой деятельности и развития личности будет автоматизировано. Рано или поздно, так или иначе :).
Вот кому стоит опасаться — так это низкоквалифицированным кадрам, потому как их рано или поздно заменят роботамипрограммами. Но случится это ещё не скоро…
Остальным стоит опасаться только катаклизмов.
Прежде чем спрашивать «кто такой программист» не плохо бы уточнить «что такое программист». Т.е. дать определение профессии, под которую ищете описание человека. Ибо с терминологией у нас тут путаница изрядная.
По миру ходит много классификаций. От банального программист-кодер до весьма развесистых сложноустроенных определений. Мне так и вовсе думается, что тут можно употребить двумерную матрицу, где по одной оси вектор кодер-конструктор, а по другой специализация. Тогда ткнув пальцем в квадрант можно указать минимальные требования к специалисту, в том числе и по знаниям математики.
PS
школу заканчивал в начале 90-х, математику помню где-то на 2-3 курс вуза… Более сложные вещи вымылись из памяти из-за неупотребимости.
ок, ок… наверно я что-то делаю не так, но мне за последние 15 лет ни разу не пришлось использовать встраиваемые скрипты с небезопасным содержимым…
И меня смутило долгое вступление про общие проблемы html, требующие аккуратного экранирования пользовательских данных.
Но если рассматривать safescript исключительно как разрешение конфликта парсеров html и script — то идея может и годная.
Но суть-то не меняется — пока что-то встраивается в код страницы минуя соответствующее экранирование, проблема будет сохраняться.
И кто защитит safescript от подобных проблем?
А я вот всё в толк не возьму, что за проблему предлагается решать столь неоднозначным способом?
Возможность "вредоносным" пользователем встроить произвольное содержание в ваш документ — это скорее фундаментальный баг разработчика. Оное содержимое может оказаться в любом месте документа, ведь никто не мешает в качестве имени при регистрации указать:
Вася"><script>alert("Aloha!");</script>
и продолжить сей фрагмент остатком оригинального тэга. Т.е. это проблема всей разметки, а не исключительно тэга script.
Точно так же и в safescript можно включить любую ересь.
Правильно говорят — на странице должен быть только константный или тщательно проверенный и экранированный контент. Остальное данные и работа с DOM. Других способов защиты нет.
<sarcasm>
ну и далее нужна картинка про 15-й стандарт :)
</sarcasm>
Да, в автомаппере гибкости много.
Да и у вас кода не мало. Может с автомапером кода в конфигурации станет чуть больше, но обвязки станет меньше, как мне кажется… да и дебажить и тестировать такой подход проще.
Или есть принципиальная потребность хранить правила в виде текста вне кода программы?
(тут, кстати, тоже есть варианты, как прикрутить конфиг из текста к автомапперу)
Может я что не так понял в постановке задачи, но почему не захотели использовать AutoMapper (или аналог) в связке с (де)сериализаторами, которые вместе можно положить в DI-контейнер и получить и мощь, и простоту, и конфигурируемость?
У меня была похожа задача — мы реализовывали работу с внешними клиентами по разным протоколам и не хотели писать конвертеры входных/выходных данных для каждого протокола/клиента (от клиента зависели некоторые правила преобразования и контроля данных). В итоге у нас получилась цепочка: входной формат — десериализация — конвертация во внутреннее представление — обработка — конвертация во внешнее представление — сериализация — выходной формат.
Через контейнер настраивались и конвертаторы и сериализаторы. На каждом этапе (включая обработку) через тот же контейнер были доступны компоненты для доступа к данным…
Ох, зря Вы так… Ведь и правда закидают.
Ваша реализация крайне небезопасна. С точки зрения механизма, у вас не токен, а сессионная кука.
Но хуже всего сама аутентификация. Серьёзно, поиск по частичному совпадению логина и пароль с чистом виде?
Настольный теннис зря забыли.
Очень поднимает тонус и годен как разминка прямо на работе.
Круглогидичен. Для начала требует минимум вложений. Занимает почти все группы мышц (не
качает, ясно дело). При правильных занятиях развивает гибкость, координацию, реакцию. Снимает застойные явления (от сидячей работы) по всему телу, особенно позвоночник и руки. А ещё это и тренировка для глаз. Низкая травмоопасность.
Существенный минус — нужен зал.
Дополнительный бонус — легко вписаться в любительские соревнования, чем добавить себе разнообразия и стимула.
И да, если заниматься серьёзно — это неплохой удар по лишнему весу.
И заниматься можно даже с избытком веса.
Тут во флэшку запихали кулхацкера, который быстро-быстро что-то печатает на клавиатуре компа :)
Т.е. тупо автоматизация того, что можно сделать и так, имея доступ к компу.
«Взлом» получится только если убедить пользователя самого воткнуть флэшку в свой комп.
Я не скажу за все СУБД, мой опыт в этой сфере ограничивается MS SQL, но решение как бы есть :)
На двух довольно ёмких и длительных проектах был успешно применён подход, реализующий оба затрагиваемых принципа. Корень подхода — дисциплина внесения изменений.
Первое железобетонное правило, за нарушение которого «били по рукам» — все изменения начинаются с написания скрипта. Никаких дизайнеров или ковыряния в базе.
Второе — скрипты должны быть не ломающими. Да, кода получается сильно больше. Приходится DDL обкладывать проверками. Но если один раз привыкнуть писать эти скрипты по определённому шаблону — оно оказывается не так уж и сложно. Одна проблема — пока не удалось автоматизировать эту работу, хотя и есть понимание, от чего можно отталкиваться и как делать. Не было времени создать инструмент. Зато эти скрипты отлично ложатся в tfs/git/etc и по истории проекта легко отслеживается суть изменений. При этом накат скриптов на базу легко автоматизируется.
Третье, уже вывод из многих раздумий… Я понимаю, почему разработчики СУБД не предлагают ничего похожего на CONVERGE — уж слишком легко сломать и не вернуть (одно спасение — бэкапы). Суть проблемы в том, что при редактировании кода мы не можем потерять клиентские данные, за их целостность отвечает тестирование продукта, а код — это только текст. Схема данных — это данные, на основании которых определяется стратегия хранения клиентских данных, и внесение изменений влечёт серьёзные последствия. И никакой инструмент не позволит себе решать, какое изменения в данных корректно, а какое нет. И по сути останутся только изменения, не модифицирующие данные, т.е. костыль.
Ах, да, суть подхода, кратко — каждое изменение атомарно, как транзакция. Обрамляется проверкой предусловий, завершается 'go'. Изменения одной задачи объединяются в один скрипт, проверяющий некую мета-информацию о базе с условием допустимости выполнения (например версию БД). Как итог — накатывать можно всю порцию скриптов. Устаревшие игнорируются, слишком новые выкидывают фатальные ошибки.
Поделюсь личным опытом. Пользуюсь Делимобилем, Белкой и Энитаймом, в сумме года два, примерно.
У делимобиля уже давно есть телеграм-поддержка, куда можно, например, написать про повреждения, приложить фотки и спокойно ехать. Раньше надо было звонить и ждать ответа оператора (по многу минут), а фотки можно было только на почту послать.
Карта у них не то, чтобы убогая, но гугловая. Путь к машине показывает, и даже пишет, сколько идти. И ещё прикольная фишка — если рядом нет машин, но вы никуда не торопитесь, можно включить «радар» и приложение вам сообщит, если в заданном радиусе появится свободная машина. Имхо, удобно где-нибудь в центе в торговом центре или кафе…
С омывайкой проблема весьма актуальна зимой, но можно купить и прислать в телеграм фото чека, обещают компенсировать (до 300р за 5 литров). Проблема только в том, что чаще всего в радиусе 5 минут от машины негде купить. Но нередко в багажнике есть запасная.
Есть ещё телеграм-бот, помогающий разобраться со стандартными проблемами.
Заправка у них только на Лукойл или Ека, по отдельным карточкам. Но для активации карты надо звонить стоя на заправке (но за последние полгода ни разу не ждал ответа более 15 секунд).
Приложение не глючит (почти). Из заметных проблем — это серьёзное обновление серверного ПО. Было время, когда авторизация слетала (давно уже). Было однажды (недели две-три чинили) когда можно было в приложении делать всё, кроме начала аренды. Оную только по звонку. Ну да, пламенный пример бэкендщикам и тестировщикам. И ещё в копилку — жутко раздражает карта, которая всё время норовит перейти в масштаб «весь город», что сразу после бронирования, что пока идёшь к машине…
При начале поездки есть возможность отказаться от дополнительной страховки за 1р/м, по умолчанию опция включена.
У белки приложение более функциональное. Найти и осуществить заправку можно через приложение. Но есть и проблемка — кнопка начала аренды примерно там, где приходится держать телефон, пока ищешь его на карте. Можно случайно нажать и потом карту уже не открыть, а машина стоит с открытыми дверями.
Кроме Киа Рио бывают Форд Фиеста, это кроме мерсов :). У Киа руль с подогревом — зимой полезно. Но почему-то нет центрального замка (ну или я не нашёл), приходится перед поездкой все двери закрывать.
Емнип, можно в настройка включить доп. страховку на время движения.
Еще они в реальном времени списывают каждые 300р оплаты (не помню, что там в правилах на тот случай, если оплата не получится).
У энитайма всё как-то иначе. Да, карты яндекс, но жутко тормозные. Что в режиме отрисовки, что пока идёшь к машине (твои координаты на карте обновляются раз-два в минуту и часто с точностью +-100 метров, что сильно мешает, пока ищешь машину во дворах).
Если в режиме аренды приложение выгрузилось по любой причине, запускается очень долго (на днях минут 5 стоял возле машины только чтобы завершить аренду).
Раньше у них тоже была только предоплата, теперь обязали привязать карту с безакцептным списанием. Но можно счёт пополнить и не только картой.
Но да, танцы с фотографированием каждый раз раздражают.
Зато (надеюсь это и сейчас так, не проверял) режим аренда/ожидание определяется автоматически (т.е. ожидание включается если двигатель заглушён и двери закрыты).
И общий вопрос-замечание: ну почему ни в одном приложении нет навигатора? хоть самого простого, какой есть в обычных картах?
А вот тут я бы поспорил…
Я не вспомню «чистое» определение, но, насколько я помню, и то и то может иметь динамический размер и разница у них в организации доступа и добавления элементов.
В том же курсе, вроде как, рассматриваются очереди и стэки…
А ещё можно повспоминать про сложность обращения к элементу и сложность вставки/удаления…
А список бывает ещё и связный и кольцевой…
Эх, с понимающим кандидатом есть что обсудить ;)
Как так-то?
Если вообще… То мне придётся вспомнить то, что изучал более 20 лет назад в чистом виде, без привязки к языку и контексту никогда не использовал. И не уверен, что вспомню что-то похоже на ту правильную формулировку, которую ожидает вопрошающий. Меня такой вопрос на собеседовании напряжёт, и даст понять, что меня тут заранее не уважают.
Но всё же, мой ответ был бы в духе «список — структура с последовательным доступом, а массив с произвольным», хотя я точно знаю, что в C# внутри List лежит Array…
Мне интересны различия, особенно, если они а) внятны и б) полезны.
Ваши термины не блещут ни тем, ни другим.
Если у нас есть кусок ткани синего цвета, то из свойств нам полезны будут размер, конкретный тон синего, тип ткани, форма… И лишь в некоем гипотетическом крайнем случае будет важно то, что все нити в этом куске синего цвета, и, о боже, любой фрагмент любой нити тоже синего цвета.
Но вопрос остаётся вез ответа — зачем делать этой крайний случай краеугольным?
ООП, как и любая другая парадигма программирования, описывает методику моделирования абстракций. С точки зрения программирования, и интервал и множество — это в первую очередь абстракции. И любой нормальный программист смоделирует их так, как это будет удобно и полезно в рамках выбранной парадигмы.
ps
«Любой нормальный» — сильное утверждение, но это моё имхо.
А зачем нам договариваться об этом тезисе?
Вы очень хотите убедить всех присутствующих в важности такого разделения между объектом и множеством, но совсем не объясняете, зачем. Зачем вводить сложность там, где реальность моделируется более простыми средствами?
И почему это вдруг в ИС не моделируются интервалы?.. И чём принципиальная разница, с точки зрения программирования, утверждений "просто существовал указанный интервал" и "он существовал в любой интервал из указанного"?
Я тут вижу три проблемы.
переименовать продуктсоздать новый продукт, когда старый перерос свои рамки.Т.е. всё решаемо, если решать и не ждать, пока наступит попаболь :)
ps. не в ту кнопочку ткнул, это был ответ olegchir
Логи, дэшборды, подсказки с коде — как по мне, так это индустриальный стандарт. Для всех, кто умеет думать наперёд, т.е. в курсе, что shit happens и всяко приятнее, когда разобраться, что к чему, можно быстро и безболезненно.
Вот только про пони всё-же перебор. Пот понадобится тебе сайт внутреннего мониторинга поднять, глядь в гит, а там Apple Dazzle погоняет Plumsweet и т.д… Мне всё же ближе нормальная доменная структура. Вариантов масса, но при единстве структуры, ориентироваться в Company/Infrastructure/Monitoring/Site сильно проще.
Бесполезно сравнивать IT с другими сферами деятельности.
Условно говоря, количество врачей/учителей/юристов/экономистов и т.д. примерно пропорционально количеству людей. В сферах же исследования и производства всё очень сильно зависит от горизонта.
Как только в какой-либо научной сфере появляются новые горизонты, образуется ниша, куда вливаются специалисты, и не важно, чем обусловлен тот горизонт — экономическими перспективами или теоретическими. Но, в первом случае там больше денег :), поэтому и специалистов там много и они не бедствуют.
Похожие дела с производством — пока очередной рынок сбыта не будет насыщен, зарплатам есть откуда браться. Но стоимость рабочей силы зависит от рынка низкоквалифицированных кадров, а стоимость управленцев определяется конкуренцией и сложностью задач. Обычно получается так, что зарплаты рабочих получают всплеск, заканчивающийся с насыщением рабочих мест, а у топов зарплаты растут, пока не кончается конкуренция.
IT-сфера имеет черты и научной деятельности и производственной. И горизонты пока только расширяются. Фокус в том, что IT проникает во все прочие сферы жизнедеятельности человечества. И границы этого проникновения не видны. Ясна только общая тенденция — всё, кроме творческой деятельности и развития личности будет автоматизировано. Рано или поздно, так или иначе :).
Вот кому стоит опасаться — так это низкоквалифицированным кадрам, потому как их рано или поздно заменят
роботамипрограммами. Но случится это ещё не скоро…Остальным стоит опасаться только катаклизмов.
По миру ходит много классификаций. От банального программист-кодер до весьма развесистых сложноустроенных определений. Мне так и вовсе думается, что тут можно употребить двумерную матрицу, где по одной оси вектор кодер-конструктор, а по другой специализация. Тогда ткнув пальцем в квадрант можно указать минимальные требования к специалисту, в том числе и по знаниям математики.
PS
школу заканчивал в начале 90-х, математику помню где-то на 2-3 курс вуза… Более сложные вещи вымылись из памяти из-за неупотребимости.
И меня смутило долгое вступление про общие проблемы html, требующие аккуратного экранирования пользовательских данных.
Но если рассматривать safescript исключительно как разрешение конфликта парсеров html и script — то идея может и годная.
А заголовок всё же слишком громкий :)
И кто защитит safescript от подобных проблем?
А я вот всё в толк не возьму, что за проблему предлагается решать столь неоднозначным способом?
Возможность "вредоносным" пользователем встроить произвольное содержание в ваш документ — это скорее фундаментальный баг разработчика. Оное содержимое может оказаться в любом месте документа, ведь никто не мешает в качестве имени при регистрации указать:
и продолжить сей фрагмент остатком оригинального тэга. Т.е. это проблема всей разметки, а не исключительно тэга script.
Точно так же и в safescript можно включить любую ересь.
Правильно говорят — на странице должен быть только константный или тщательно проверенный и экранированный контент. Остальное данные и работа с DOM. Других способов защиты нет.
<sarcasm>
ну и далее нужна картинка про 15-й стандарт :)
</sarcasm>
Да и у вас кода не мало. Может с автомапером кода в конфигурации станет чуть больше, но обвязки станет меньше, как мне кажется… да и дебажить и тестировать такой подход проще.
Или есть принципиальная потребность хранить правила в виде текста вне кода программы?
(тут, кстати, тоже есть варианты, как прикрутить конфиг из текста к автомапперу)
У меня была похожа задача — мы реализовывали работу с внешними клиентами по разным протоколам и не хотели писать конвертеры входных/выходных данных для каждого протокола/клиента (от клиента зависели некоторые правила преобразования и контроля данных). В итоге у нас получилась цепочка: входной формат — десериализация — конвертация во внутреннее представление — обработка — конвертация во внешнее представление — сериализация — выходной формат.
Через контейнер настраивались и конвертаторы и сериализаторы. На каждом этапе (включая обработку) через тот же контейнер были доступны компоненты для доступа к данным…
Ваша реализация крайне небезопасна. С точки зрения механизма, у вас не токен, а сессионная кука.
Но хуже всего сама аутентификация. Серьёзно, поиск по частичному совпадению логина и пароль с чистом виде?
Очень поднимает тонус и годен как разминка прямо на работе.
Круглогидичен. Для начала требует минимум вложений. Занимает почти все группы мышц (не
качает, ясно дело). При правильных занятиях развивает гибкость, координацию, реакцию. Снимает застойные явления (от сидячей работы) по всему телу, особенно позвоночник и руки. А ещё это и тренировка для глаз. Низкая травмоопасность.
Существенный минус — нужен зал.
Дополнительный бонус — легко вписаться в любительские соревнования, чем добавить себе разнообразия и стимула.
И да, если заниматься серьёзно — это неплохой удар по лишнему весу.
И заниматься можно даже с избытком веса.
Т.е.
тупоавтоматизация того, что можно сделать и так, имея доступ к компу.«Взлом» получится только если убедить пользователя самого воткнуть флэшку в свой комп.
На двух довольно ёмких и длительных проектах был успешно применён подход, реализующий оба затрагиваемых принципа. Корень подхода — дисциплина внесения изменений.
Первое железобетонное правило, за нарушение которого «били по рукам» — все изменения начинаются с написания скрипта. Никаких дизайнеров или ковыряния в базе.
Второе — скрипты должны быть не ломающими. Да, кода получается сильно больше. Приходится DDL обкладывать проверками. Но если один раз привыкнуть писать эти скрипты по определённому шаблону — оно оказывается не так уж и сложно. Одна проблема — пока не удалось автоматизировать эту работу, хотя и есть понимание, от чего можно отталкиваться и как делать. Не было времени создать инструмент. Зато эти скрипты отлично ложатся в tfs/git/etc и по истории проекта легко отслеживается суть изменений. При этом накат скриптов на базу легко автоматизируется.
Третье, уже вывод из многих раздумий… Я понимаю, почему разработчики СУБД не предлагают ничего похожего на CONVERGE — уж слишком легко сломать и не вернуть (одно спасение — бэкапы). Суть проблемы в том, что при редактировании кода мы не можем потерять клиентские данные, за их целостность отвечает тестирование продукта, а код — это только текст. Схема данных — это данные, на основании которых определяется стратегия хранения клиентских данных, и внесение изменений влечёт серьёзные последствия. И никакой инструмент не позволит себе решать, какое изменения в данных корректно, а какое нет. И по сути останутся только изменения, не модифицирующие данные, т.е. костыль.
Ах, да, суть подхода, кратко — каждое изменение атомарно, как транзакция. Обрамляется проверкой предусловий, завершается 'go'. Изменения одной задачи объединяются в один скрипт, проверяющий некую мета-информацию о базе с условием допустимости выполнения (например версию БД). Как итог — накатывать можно всю порцию скриптов. Устаревшие игнорируются, слишком новые выкидывают фатальные ошибки.
У делимобиля уже давно есть телеграм-поддержка, куда можно, например, написать про повреждения, приложить фотки и спокойно ехать. Раньше надо было звонить и ждать ответа оператора (по многу минут), а фотки можно было только на почту послать.
Карта у них не то, чтобы убогая, но гугловая. Путь к машине показывает, и даже пишет, сколько идти. И ещё прикольная фишка — если рядом нет машин, но вы никуда не торопитесь, можно включить «радар» и приложение вам сообщит, если в заданном радиусе появится свободная машина. Имхо, удобно где-нибудь в центе в торговом центре или кафе…
С омывайкой проблема весьма актуальна зимой, но можно купить и прислать в телеграм фото чека, обещают компенсировать (до 300р за 5 литров). Проблема только в том, что чаще всего в радиусе 5 минут от машины негде купить. Но нередко в багажнике есть запасная.
Есть ещё телеграм-бот, помогающий разобраться со стандартными проблемами.
Заправка у них только на Лукойл или Ека, по отдельным карточкам. Но для активации карты надо звонить стоя на заправке (но за последние полгода ни разу не ждал ответа более 15 секунд).
Приложение не глючит (почти). Из заметных проблем — это серьёзное обновление серверного ПО. Было время, когда авторизация слетала (давно уже). Было однажды (недели две-три чинили) когда можно было в приложении делать всё, кроме начала аренды. Оную только по звонку. Ну да, пламенный пример бэкендщикам и тестировщикам. И ещё в копилку — жутко раздражает карта, которая всё время норовит перейти в масштаб «весь город», что сразу после бронирования, что пока идёшь к машине…
При начале поездки есть возможность отказаться от дополнительной страховки за 1р/м, по умолчанию опция включена.
У белки приложение более функциональное. Найти и осуществить заправку можно через приложение. Но есть и проблемка — кнопка начала аренды примерно там, где приходится держать телефон, пока ищешь его на карте. Можно случайно нажать и потом карту уже не открыть, а машина стоит с открытыми дверями.
Кроме Киа Рио бывают Форд Фиеста, это кроме мерсов :). У Киа руль с подогревом — зимой полезно. Но почему-то нет центрального замка (ну или я не нашёл), приходится перед поездкой все двери закрывать.
Емнип, можно в настройка включить доп. страховку на время движения.
Еще они в реальном времени списывают каждые 300р оплаты (не помню, что там в правилах на тот случай, если оплата не получится).
У энитайма всё как-то иначе. Да, карты яндекс, но жутко тормозные. Что в режиме отрисовки, что пока идёшь к машине (твои координаты на карте обновляются раз-два в минуту и часто с точностью +-100 метров, что сильно мешает, пока ищешь машину во дворах).
Если в режиме аренды приложение выгрузилось по любой причине, запускается очень долго (на днях минут 5 стоял возле машины только чтобы завершить аренду).
Раньше у них тоже была только предоплата, теперь обязали привязать карту с безакцептным списанием. Но можно счёт пополнить и не только картой.
Но да, танцы с фотографированием каждый раз раздражают.
Зато (надеюсь это и сейчас так, не проверял) режим аренда/ожидание определяется автоматически (т.е. ожидание включается если двигатель заглушён и двери закрыты).
И общий вопрос-замечание: ну почему ни в одном приложении нет навигатора? хоть самого простого, какой есть в обычных картах?
Я не вспомню «чистое» определение, но, насколько я помню, и то и то может иметь динамический размер и разница у них в организации доступа и добавления элементов.
В том же курсе, вроде как, рассматриваются очереди и стэки…
А ещё можно повспоминать про сложность обращения к элементу и сложность вставки/удаления…
А список бывает ещё и связный и кольцевой…
Эх, с понимающим кандидатом есть что обсудить ;)
Но реально, часто задают такие вопросы ожидая ровно одного «правильного» ответа :(
Если вообще… То мне придётся вспомнить то, что изучал более 20 лет назад в чистом виде, без привязки к языку и контексту никогда не использовал. И не уверен, что вспомню что-то похоже на ту правильную формулировку, которую ожидает вопрошающий. Меня такой вопрос на собеседовании напряжёт, и даст понять, что меня тут заранее не уважают.
Но всё же, мой ответ был бы в духе «список — структура с последовательным доступом, а массив с произвольным», хотя я точно знаю, что в C# внутри List лежит Array…