Я смотрел на medium instance для себя, для долговременного сервера, и добавил расходы на предполагаемые диски, трафик и т.п. — они выходят константные для любого размера инстанса.
С этими раходами стоимость small instance подскакиваыет почти до стоимости medium instance.
А вот такой вопрос — если я оплачу план на 3 года, и в течении этих 3 лет мне надо будет что-то масштабное сделать с этим инстансом (пересоздать заново), то мне типа придется заново за 3 года платить? Кто знает?
После общения с denssy поигрался с запросами применительно к нашим задачам по сельскому хозяйству.
Поискал погоду для наших полей в Израиле (не точная локация, но примерно в районе).
Нашлись 3 аэропорта в радиусе 100 км, ближайший в 28 километрах. Благо страна маленькая.
Но кроме аэропортов, больше станций нет.
Поискал в Испании, где у нас пилотные проекты — взял к примеру какое-то поле.
Опять-же 2 аэропорта в радиусе 100 км, ближайший в 72 километрах.
Подумал про Штаты, в которых больше публично доступных данных.
Ткнул в какое-то поле в Вирджинии.
Станций значительно больше — 14 в радиусе 100 км, но ближайшая в 49 километрах.
Тут, на самом деле, уже можно было-бы интерполировать (если распределение станций позволяет).
Если-бы не как минимум одно но — нет высоты станций над уровнем моря.
Допустим, мое поле на 500 метрах, а станция метров на 800 выше или ниже — в Испании на севере сплошь и рядом такая ситуация.
Вторая загвоздка — множество станций не выдают данные в реальном времени, а запаздывают — до часа в лучшем случае, а иногда даже на 2-3 часа. Чтобы знать, насколько можно на данные с конкретной станции полагаться, надо знать, во сколько они были получены. Хотя я еще не пробовал выборку по конкретной станции — только поиск станций.
Пока нам пригодится для демонстраций, но надеюсь что инициатива будет шириться :-) и станций станет достаточно для (наших) практических целей.
На температуру можно таким образом полагаться — дешевые датчики достаточно точные.
Ветер, допустим, можно попробовать усреднить. Влажность… может быть, не уверен.
Дешевые (или неоткалиброванные) датчики влажности страдают недостаточной точностью, например, при превышении некоторого порога (70-80-90%) тупо выдают 100% — такие характерные «плато». А для наших задач, к примеру, нужно ловить диапазон 88-92% — и неточные датчики становятся бесполезными.
Или, например, новые дешевые датчики влажности, погружаемые в почву, которые реагируют на изменение сопротивления, страдают от отсутствия калибровки для конкретного типа почвы и солености воды — а их тупо втыкают как придется. Старые датчики с водяным столбиком внутри не зависят от типа почвы, но зато нуждаются в обслуживании, и за это их не любят.
На самом деле я не спец в этом — так, нахватался от наших агрономов.
Достоверность прогноза на сутки составляла порядка 80%
Данные нашего последнего поставщика прогноза погоды очень хорошо коррелируют с актуальными данными — графики почти друг на друге. Для наших задач (сельское хозяйство, борьба с вредителями) хватает.
Редакт.:
То есть, даже если климатической модели всей планеты и нет, локальные задачи решать можно.
Мы разрабатываем софт для сельского хозяйства и активно используем данные о погоде, в том числе прогноз погоды с привязкой к километровой сетке. Постоянно сталкиваемся с двумя проблемами — часто местные метео-станции неоткалиброваны и выдают неточную информацию — это особенно критично с влажностью; а вторая проблема — не хватает станций, с которыми можно работать через Web несложным способом. Ну и прогнозы (математические модели привязки к местности), конечно, бывают очень разного качества.
У вас написано про 40000 станций — на карте видны только аэропорта и совсем немного станций — почему?
И насчет монетизации, ИМХО, вам надо сразу задумываться.
Одно время у них ноуты были очень неплохие по соотношению цена/качество. Но последние несколько лет качество упало (у многих знакомых ноуты DELL начали умирать).
Как минимум, когда я пишу exception-safety код, я обращаю внимание на спецификацию вызываемых функций.
Вы проверяете, и я проверяю (и то я себе в данном случае не доверяю), а 10 соседей не проверяют — как можно потом на результат положиться? Мы поэтому и отказались от throw(), так как компилятор ничего не проверяет, а отследить вручную корректность этой спецификации невозможно.
Также nothrow спецификация move конструкторов требуется в контейнерах, чтобы гарантировать безопасное перемещение элементов.
Ок, как я написал, для разработчиков стандартной библиотеки какая-то польза может быть.
Безусловно, лучше не писать nothrow, если нет уверенности. В C++ полно вещей, которыми можно отстреливать ноги :)
И поэтому мы остаемся при промышленной разработке со старым добрым С с объектами, и не дай бог какую новую фичу применить :-)
А сам nothrow лишь возможность вынести спецификации на уровень языка (и дать возможность анализировать её компилятору)
Беда в том, что компиляторы не проверяют эти спецификации во время компиляции… или не все компиляторы, или не всегда. И хорошая идея превращается в пшик. Особенно критично при кросс-платформенной разработке с поддержкой всяких допотопных компиляторов типа IBM xlC и Sun (sorry, Oracle) CC — каждый интерпретирует стандарт по своему.
попытка выбросить исключение, не соотвествующее спецификации throw(), из функции, приводит к вызову std::unexpected() и аварийному завершению программы.
Теперь народ навешивает throw() на всякие тривиальные однострочные функции, свято веря, что они ни при каких обстоятельствах не бросают исключений. А про копирование объектов забывают, и в результате рано или поздно мы попадаем в std::unexpected(). А без спецификаций исключение было-бы корректно обработано и записано в лог.
Спорная это штука — noexcept… мы в свое время от использования пустого throw() в объявлениях функций отказались, так как это получалась ужасно деструктивная конструкция — в С++ очень много вещей, способных бросить исключение, и черемерное увлечение throw() приводило к падению программ в ситуациях, когда исключение было-бы обработано без проблем. Никакой пользы от throw() не было — один вред.
Теперь с этой новой конструкцией noexcept, нет никакого улучшения, кроме обещания, что компиляторы будут проверять условие во время компиляции (сомнительно, что смогут в реальной жизни из-за виртуальных функций, и еще более сомнительно, что все разработчики компиляторов сделают это единообразно).
То есть фича получилась только для разработчиков стандартной библиотеки, и даже там не везде будет применимо, ИМХО.
А народ будет ее пытаться в реальном коде использовать, и наступать на те-же грабли, что и с throw().
Я живу ни Линухе и пользуюсь LO, но зачастую приходится пересаживаться за соседний комп с виндой и работать с документами из MSO. Например, LO Calc не справляется с большими XLSX файлами (5-8 мег, 16к строк и куча столбцов) — при открытии виснет на несколько минут со 100% CPU, пока у меня терпение не кончается, и я его не убиваю. Форматирование тоже плывет часто, так что приходится окончательную доводку проводить в MSO. А для работы с черновиками и некритичными документами LO вполне подходит.
Не хватает таблицы с ценами, хотя-бы ориентировочными, и таблицы с результатами тестов, потому-что на скриншотах очень плохо видно цифры (или мне нужны очки).
Я смотрел на medium instance для себя, для долговременного сервера, и добавил расходы на предполагаемые диски, трафик и т.п. — они выходят константные для любого размера инстанса.
С этими раходами стоимость small instance подскакиваыет почти до стоимости medium instance.
А вот такой вопрос — если я оплачу план на 3 года, и в течении этих 3 лет мне надо будет что-то масштабное сделать с этим инстансом (пересоздать заново), то мне типа придется заново за 3 года платить? Кто знает?
Сейчас перекачал — то же самое.
$ md5sum html_parser_bench.tar.bz2
cbe8903fc6803587900d474d35053793 html_parser_bench.tar.bz2
У меня Debian testing
$ bunzip2 html_parser_bench.tar.bz2
bunzip2: html_parser_bench.tar.bz2: trailing garbage after EOF ignored
Поискал погоду для наших полей в Израиле (не точная локация, но примерно в районе).
Нашлись 3 аэропорта в радиусе 100 км, ближайший в 28 километрах. Благо страна маленькая.
Но кроме аэропортов, больше станций нет.
Поискал в Испании, где у нас пилотные проекты — взял к примеру какое-то поле.
Опять-же 2 аэропорта в радиусе 100 км, ближайший в 72 километрах.
Подумал про Штаты, в которых больше публично доступных данных.
Ткнул в какое-то поле в Вирджинии.
Станций значительно больше — 14 в радиусе 100 км, но ближайшая в 49 километрах.
Тут, на самом деле, уже можно было-бы интерполировать (если распределение станций позволяет).
Если-бы не как минимум одно но — нет высоты станций над уровнем моря.
Допустим, мое поле на 500 метрах, а станция метров на 800 выше или ниже — в Испании на севере сплошь и рядом такая ситуация.
Вторая загвоздка — множество станций не выдают данные в реальном времени, а запаздывают — до часа в лучшем случае, а иногда даже на 2-3 часа. Чтобы знать, насколько можно на данные с конкретной станции полагаться, надо знать, во сколько они были получены. Хотя я еще не пробовал выборку по конкретной станции — только поиск станций.
Пока нам пригодится для демонстраций, но надеюсь что инициатива будет шириться :-) и станций станет достаточно для (наших) практических целей.
Ветер, допустим, можно попробовать усреднить. Влажность… может быть, не уверен.
Дешевые (или неоткалиброванные) датчики влажности страдают недостаточной точностью, например, при превышении некоторого порога (70-80-90%) тупо выдают 100% — такие характерные «плато». А для наших задач, к примеру, нужно ловить диапазон 88-92% — и неточные датчики становятся бесполезными.
Или, например, новые дешевые датчики влажности, погружаемые в почву, которые реагируют на изменение сопротивления, страдают от отсутствия калибровки для конкретного типа почвы и солености воды — а их тупо втыкают как придется. Старые датчики с водяным столбиком внутри не зависят от типа почвы, но зато нуждаются в обслуживании, и за это их не любят.
На самом деле я не спец в этом — так, нахватался от наших агрономов.
Данные нашего последнего поставщика прогноза погоды очень хорошо коррелируют с актуальными данными — графики почти друг на друге. Для наших задач (сельское хозяйство, борьба с вредителями) хватает.
Редакт.:
То есть, даже если климатической модели всей планеты и нет, локальные задачи решать можно.
Мы разрабатываем софт для сельского хозяйства и активно используем данные о погоде, в том числе прогноз погоды с привязкой к километровой сетке. Постоянно сталкиваемся с двумя проблемами — часто местные метео-станции неоткалиброваны и выдают неточную информацию — это особенно критично с влажностью; а вторая проблема — не хватает станций, с которыми можно работать через Web несложным способом. Ну и прогнозы (математические модели привязки к местности), конечно, бывают очень разного качества.
У вас написано про 40000 станций — на карте видны только аэропорта и совсем немного станций — почему?
И насчет монетизации, ИМХО, вам надо сразу задумываться.
Вы проверяете, и я проверяю (и то я себе в данном случае не доверяю), а 10 соседей не проверяют — как можно потом на результат положиться? Мы поэтому и отказались от throw(), так как компилятор ничего не проверяет, а отследить вручную корректность этой спецификации невозможно.
Ок, как я написал, для разработчиков стандартной библиотеки какая-то польза может быть.
И поэтому мы остаемся при промышленной разработке со старым добрым С с объектами, и не дай бог какую новую фичу применить :-)
Беда в том, что компиляторы не проверяют эти спецификации во время компиляции… или не все компиляторы, или не всегда. И хорошая идея превращается в пшик. Особенно критично при кросс-платформенной разработке с поддержкой всяких допотопных компиляторов типа IBM xlC и Sun (sorry, Oracle) CC — каждый интерпретирует стандарт по своему.
Теперь народ навешивает throw() на всякие тривиальные однострочные функции, свято веря, что они ни при каких обстоятельствах не бросают исключений. А про копирование объектов забывают, и в результате рано или поздно мы попадаем в std::unexpected(). А без спецификаций исключение было-бы корректно обработано и записано в лог.
Теперь с этой новой конструкцией noexcept, нет никакого улучшения, кроме обещания, что компиляторы будут проверять условие во время компиляции (сомнительно, что смогут в реальной жизни из-за виртуальных функций, и еще более сомнительно, что все разработчики компиляторов сделают это единообразно).
То есть фича получилась только для разработчиков стандартной библиотеки, и даже там не везде будет применимо, ИМХО.
А народ будет ее пытаться в реальном коде использовать, и наступать на те-же грабли, что и с throw().
Также раньше, AFAIR в старых gcc, некоторые оптимизации О3 могли привести к некорректному коду. Но в новых версиях gcc такого уже не должно быть.
Там просто один разработчик за это берется, и у него скилл оценки объемов работ по-моему нифига не прокачан