Как я понимаю, если обязать поисковые системы индексировать только достижимые из открытого интернета страницы — проблему можно решить. Это было бы правильно с точки зрения этики.
Честно говоря сначала подумал статья с лейтмотивом «лучше сами запрограммим потому что сами и умеем программить». А так полностью поддерживаю. Размер геморроя по собственной интеграции платежных системам условно постоянен и не зависит от оборотов. А комиссия, которая платится стороннему интегратору — пропорциональна обороту. Считаем и делаем как дешевле.
Сейчас вспомнилось, пару лет назад мне один менеджер одного интегратора упоминал некую локальную авиа-компанию как их клиента. Лукавил, наверное :)
Я писал, веб-приложение веб-приложению рознь. Если манипуляции (в том числе отображение) вынесены на клиентскую часть, то как там оно хранится — личное дело сервера. В том смысле, что данные можно (хотя нет — желательно) хранить в некотором унифицированном виде и никак не преобразовывать — только отдавать и записывать. Тогда и пример с супругами в Лондоне и Киеве будет работать логично.
А вот если клиент тонкий, то естественно, часть (или все) подобных манипуляций с датами происходит на сервере. Что вызывает естественное желание спихнуть эту задачу на встроенные возможности того же СУБД.
Если речь о чем-то вроде date_default_timezone_set — то нет. Но, скажем так, при хорошо спроектированной архитектуре это ведь не проблема. Если за обработку полученных с сервера данных, и за подготовку их к отправке отвечает некоторая прослойка — то совершенно не проблема заставить ее, в случае дат — делать прямое/обратное преобразование с учетом Date().getTimezoneOffset(). А если асинхронность приложения сделана кусочно-гнездовым способом — то тут уж неча на зеркало пенять…
Веб-приложение веб-приложению рознь. У нас тоже была подобная проблема. Один из супругов в командировке в Лондоне, супруга дома в Киеве. Оба одновременно делают запись о расходах в свой общий бюджетный аккаунт. Помимо вопроса «как хранить» есть еще вопрос «как отображать». В нашем случае веб-приложение — полностью на JS а данные приходят в браузер сыром виде. Поэтому хранятся и передаются данные в UTC, а уже в браузере преобразовываются во временную зону ОС. И наоборот: перед отправкой даты временные метки переводятся из локальных в UTC/
Т.е. если супруги запишут одновременно операции (в 1:00 по Киеву и в 23:00 по Лондону) увидят эти операции одновременными, но у супруга они обе будут датированы допустим 17-тым июля, а у супруги — 18-тым.
Спасибо.
В моем случае в процессе счета находятся расстояния от узла сетки до всех достижимых от него изолиний (без пересечения других изолиний). И кроме того расстояния берутся не по прямой — а кротчайшие в обход других изолиний.
Нет ли у вас исходного изображения (черный фон + синие изолинии) но без сглаживания, чтобы все пиксели изолинии были исключительно одного цвета? Очень интересно посчитать задачу своим алгоритмом построения цветовых градиентов.
Я особо не вдавался в эмпирические тонкости построения рельефа. Но разве требования к алгоритму «с одной стороны изолинии — выше, с другой — ниже» не достаточно для того, чтобы соблюсти гидрологическую корректность? В смысле, если долина реки нормально описана изолиниями — то модель с указанным свойством не будет корректна?
Отвечу за себя. Кригинг работает с точечными высотными отметками, а не изолиниями. Триангуляция же дает плоское плато в т.н. «карманах». Я (не автор статьи, ссылка на статью с иллюстрацией результатов есть выше в моем комментарии) использовал оригинальный статистический алгоритм, который работает с изолиниями именно как с линиями. Это дает множество плюсов. Во-первых качество дискретизации изолинии (количество точек, формирующих ломанную изолинии) качественно не влияет на результат. Во-вторых сеточная функция при «подходе» к линии изолинии принимает значение близкое к высоте изолинии. В-третьих — полное отсутствие плато, свойственное алгоритмам на основе триангуляции. Ну и кроме того алгоритм имеет очень хорошую асимптотическую сложность (линейный относительно произведения размерности сетки и количества изолиний).
Очень интересно послушать про «качественный и простой алгоритм получения равномерной сетки». Я в свое время тоже решал задачу восстановления 3д модели рельефа по изолиниям. Правда у меня сеточная функция была конечной целью.
Недавно попробовал тот же алгоритм для решения задачи построение цветовых градиентов (вот здесь есть старые примеры habrahabr.ru/qa/3135/) — получилось очень даже неплохо. Сделал на основании него рисовалку для андроида — дети в восторге :)
Я пару недель следил ежедневно — ну интересно было, чего уж там. Так вот выходило что статистика за «вчера» появлялась сегодня с 12-00 до 15-00, потом числа 19 залипла на пару дней. А потом залипла с концами.
Сейчас вспомнилось, пару лет назад мне один менеджер одного интегратора упоминал некую локальную авиа-компанию как их клиента. Лукавил, наверное :)
А вот если клиент тонкий, то естественно, часть (или все) подобных манипуляций с датами происходит на сервере. Что вызывает естественное желание спихнуть эту задачу на встроенные возможности того же СУБД.
date_default_timezone_set— то нет. Но, скажем так, при хорошо спроектированной архитектуре это ведь не проблема. Если за обработку полученных с сервера данных, и за подготовку их к отправке отвечает некоторая прослойка — то совершенно не проблема заставить ее, в случае дат — делать прямое/обратное преобразование с учетомDate().getTimezoneOffset(). А если асинхронность приложения сделана кусочно-гнездовым способом — то тут уж неча на зеркало пенять…Т.е. если супруги запишут одновременно операции (в 1:00 по Киеву и в 23:00 по Лондону) увидят эти операции одновременными, но у супруга они обе будут датированы допустим 17-тым июля, а у супруги — 18-тым.
В моем случае в процессе счета находятся расстояния от узла сетки до всех достижимых от него изолиний (без пересечения других изолиний). И кроме того расстояния берутся не по прямой — а кротчайшие в обход других изолиний.
Вот что получилось (обычный дектоп, сетка пиксельная, счет около 2 секунд)
Недавно попробовал тот же алгоритм для решения задачи построение цветовых градиентов (вот здесь есть старые примеры habrahabr.ru/qa/3135/) — получилось очень даже неплохо. Сделал на основании него рисовалку для андроида — дети в восторге :)