Для решения конкретно вашей задачи давно уже существует proj_lib Но беда в том, что не существует ни одной 100% адекватной проекции. Да и системами координат и геоидами не все так просто. А для выбора правильной проекции под задачу иногда бывает важно понимать какая из существующих будет лучше.
Ну и еще один аспект. Бывает что программист работает по ТЗ. Где написано «возьми то и положи туда». Это работа не разработчика а кодировщика. Тут действительно ничего особо знать не нужно кроме как нарисовать семь красных линий одной строкой кода.
А бывает что разработчику дается полноценное FSD — «на входе имеем то, на выходе нужно получить это». А выбор алгоритма и его реализации уже полностью на совести разработчика. И очень часто необходимость разработки нового возникает потому что ни один из 100500 существующих продуктов не устраивает по каким-то критериям. А это значит, что нужно придумывать что-то новое, а не то что выдается гуглем в первых пяти строках поиска.
Впрочем, это отдельная тема про различия разработчика и кодировщика.
Тут дело в другом. GPS достаточно точно измеряет скорость (измерения основаны на эффекте Доплера, подробности можно нагуглить — статей на эту тему достаточно много) при условии прямолинейного равномерного движения. Например, на автомобиле, когда прибор лежит на передней панели (например) и машина движется примерно с одинаковой скоростью. Тогда погрешность измерения невелика — порядка 0.1 м/с.
При катании на лыжах ситуация радикально иная. Во-первых, лыжник все-таки движется дугами т.е. постоянно меняет направление. Во-вторых, прибор обычно лежит в кармане где-то в верхней половине корпуса. Т.е. при перекантовках и смене ангуляции прибор вместе с корпусом совершает резкое движение перпендикулярно траектории.
Все это резко повышает погрешность измерения скорости и в максималку может попасть не скорость лыжника, а вот эта скорость самого прибора в момент перекантовки.
Я накопил достаточно большую коллекцию треков, записанных логгером (он тупо пишет nmea поток с чипа с частотой 5 точек в секунду на карту памяти). Просмотр таких треков по точкам показывает кратковременные рывки скорости именно в такие моменты, как указано выше.
Методика спидсерферов такая — в зачет идет усредненная на 5-10 секунд скорость на прямолинейном отрезке. Это более адекватный параметр. Возможно, там еще отбрасываются «хвосты» по правилу трех сигм. У них есть специальный софт для анализа треков и участники просто присылают свои треки, а результаты уже выдаются софтом.
У мобильных приложений далеко не у всех заложена хоть какая-то фильтрация. Многие выводят напрямую то, что прилетело с чипа.
Я далеко не все смотрел, из точно фильтрующих видел meRun (для андроида, для Blackberry пользуюсь ей же, там называется CascaRun). Правда, описания алгоритма фильтрации не знаю. Но какие-то настройки фильтров там есть.
Для компа сам писал анализатор треков. Там много всяких фильтров для прочистки треков и удаления недостоверных (в т.ч. и по скорости) точек и подсчета статистики.
Значит просто не попадалось еще соответствующих задач… Вот поставят задачу написания какой-нибудь навигационной системы — придется и с проекциями разбираться и с системами координат и с переводом из одной проекции в одной системе координат в другую в другой системе координат (скажем, от меркатора в WGS84 к Гаусс-Крюгеру в Пулково-1942). Тут придется немножко математику вспомнить. А если потребуется еще сохранять треки, то потребуется фильтрация — фильтр Калмана хотя бы понять как работает и как им пользоваться. Или обосновать что более простые аналоги типа двойного экспоненциального сглаживания в некоторых ситуациях работают не хуже. Как можно использовать сплайн-сглаживание или прикрутить фильтр Ходрика-Прескота (который придумывался совсем не для того). Ну про прореживание фильтром Дугласа-Пеккера как-бы и неудобно говорить — это азы.
А если потребуется еще и маршруты строить, то тут теория графов в полный рост…
Так что или не зарекаться что никогда не понадобиться, или заранее исключить для себя определенные области разработки.
Сам до недавнего времени пользовался связкой планшет — кнопочная звонилка. Сейчас, увы, опопсился и перешел на смартфон (ну, правда, тут тоже не без «нестандартности» :-)
Так что более чем понимаю такое решение :-)
Правда, я равнодушен к визуальным финтифлюшкам, не люблю писать интерфейсы, люблю глубокий backend и получаю удовольствие от отладки системным отладчиком в зеленом экране (эмулятор терминала IBM5250)
Речь не о субметровой точности (там нет зконодательных ограничений, насколько я в курсе, там ограничения технического характера), речь о бреде, который эти программы выводят на экран.
Есть мобильные приложения — спортвные трекеры. Например, катаемся на горных лыжах, на телефоне запущено такое приложение. По итогу оно нам показывает суммарный набор-потерю высоты, сколько по расстоянию накатали, максимальную скорость на спуске. Так вот периодически люди (обычно новички) в профильных форумах начинают хватстаться что у них где-то там максимальная скорость была аж 120км/ч (порядок величин такой). при том, что такая скорость характерна для спортсменов на соревнованиях по скоростному спуску на этапах КМ. Но те-то едут в обтекаемых комбезах в низкой аэродинамической стойке на 2+ м спусковых лыжах и по очень жесткой трассе. Для любителя в куртке и широких штанах на обычных лыжах такое в принципе недостижимо.
Да, такая цифра может придти с чипа, но надо понимать откуда она взялась и как соотносится с реальностью. На тему измерения скорости с помощью GPS написано много статей с разбором в каких ситуациях какая погрешность возможна. Есть сообщество спидсерферов (speedsurfing), которые измеряют скорость с помощью GPS и сравнивают ее с другими — у них разработаны методики записи и обработки треков для получения адекватных сравнимых величин.
Но во все это надо вникать, разбираться. А в мобильную разработку пришло огромное количество… даже не знаю как назвать… людей, которые больше озабочены проблемами монетизации, чем реальной полезностью своей разработки.
Второй пример, с теми же трекерами. Велсипед. Человек покатался по парку (условно) и хвастается что у него суммарный набор высоты аж полтора километра. Ага. На 30-50 километров пути. Родной, откуда? Ты в Альпах через перевалы катался?
Опять нужно понимать, что точность определения высоты в силу физики процесса в GPS на порядок ниже точности определения координат. И в отсутствии барометрического альтиметра в приборе высота даже стоя на месте будет «плавать» и накручивать «суммарный набор». А при наличии оного его нужно регулярно калибровать.
Кроме того, суммарный набор неплохо накручиватеся на мелких кочках. Метр туда, метр сюда, глядишь и полтора километра набежало.
Все это нужно фильтровать и указывать что набрал столько-то при таких-то настройках (скажем, не учитывал наборы на уклонах меньше одного градуса, не учитывал единичные перепады менее полутора метров и т.п.)
Меня больше всего поразило, что научные статьи по физике и химии были написаны без единой математической формулы и практически без расчётов
Это как раз не удивительно. Физика суть наука описательная. И в ней главное понимать как оно все между собой взаимодействует на некотором интуитивном уровне, чем уметь на каждый случай написать формулу для получения нужного ответа.
Есть у меня знакомый, занимается репетиторством по физике. Так вот у него методика сторится на том, что сналала все описывается «на пальцах», без формул. Затем вводятся понятия «базовых величин» (расстояние, время, температура, масса...) Затем переход от базовых к величинам производным (как из рассотяния и времени получить скорость и т.п.). А затем уже то, что описано на пальцах описывается формулами.
Когда он эту методику начал применять на практике, то был сам поражен насколько быстро те, кому физика в школе ну совсем никак не лезет в голову, начинали понимать ее суть и прогрессировать.
Необходимость математики лучше доказывать на реальных задачах из личной практики. С разбором как она решается (или скорее не решается) человеком не знающим математики и как она решается (успешно) человеком, способным применять математический аппарат на практике.
На мейнфреймах с железом все в порядке — тестовый IBM Power S824 (18 ядер, 1.85Тб RAM, SSD дисковые массивы 67 + 15Тб). На проде помощнее (но там и задач намного больше крутится) — S828. Точных характеристики не знаю
Общий посыл такой — загрузить под завязку можно любую систему. И чем меньше думать об оптимальности кода при разработке, тем быстрее этот момент наступит. Заниматься переоптимизацией того, что уже работает намного сложнее хотя бы потому, что каждое изменение кода требует потом длительной серии ретестов на неухудшение функциональности.
Поменять железо на помощнее (любимая отмазка плохих разработчиков — «тормозит потому что железо слабое, проапгрейдитесь и все будет ок») не вариант — затраты (даже не считая стоимости самого железа в несколько сотен килобаксов) по переносу всего и вся на новые железяки космические.
Простейший пример с прошлой работы. Была задача по разработке системы мониторинга инженерного оборудования зданий. В качестве одного из конкретных применений — система ЛДСС (лифтовая диспетчерская связь и сигнализация). Так вот, есть ПУБЭЛ (правила установки и безопасной эксплуатации лифтов), согласно которым лифт не имеет права работать без работающей системы ЛДСС. Это значит, что если вы захотите на работающем объекте переустановить (скажем, поставить новую версию) систему, то сначала вы должны отключить все лифты к ней подключенные. Т.е. физически их остановить и заблокировать. А в современных версиях их может быть несколько сотен (штук 300 даже на одной не очень большой диспетчерской). И раскиданы они по всему городу (связь идет по IP каналам). И далеко не все модели могут быть остановлены и заблокированы дистеанционно. Представляете ситуацию — бригады аварийщиков носятся по городу и останавливают лифты просто потому что вам запотимело совтину поменять?
Здесь все еще серьезнее. На порядки.
Масштабы страны во-первых, во-вторых останавливать нельзя. только вводить параллельно, потом убедиться что все работает и только потом выводить старое.
Так что единственный вариант — сразу писать оптимальный код. Для особо критических задач проводить нагрузочное тестирование (это кроме компонентного, интеграционного и бизнес).
Так что над каждой задачей приходится думать. И каждое решение переосмысливать — а можно ли написать оптимальнее? А как можно скроить на количестве ресурсоемких операций? Что вынести в инициализацию чтобы выполнялось один раз, а что придется делать на каждом обороте цикла? Как оптимально распределить функции между master`ом и worker`ами при распараллеливании обработки и как эффективно организовать межпроцессную коммуникацию.
Это то, что касается оптимизации.
Собственно по математике. Достаточно много задач, где математика особо и не нужна. А есть где нужна. На совей спрактике когда-то давно приходилось заниматься разработкой программ для обработки экспериментальных данных. Там использовались методы регрессионного анализа (в те времена книга Грейпера и Смита «Прикладной регрессионный анализ» была настольной). Потом немного коснулся темы молекулярной динамики и машинного моделирования (там и физика — статфизика и математика: микро- и макроканонические ансамбли, связь между функцией распределения параметров отдельных молекул с макропараметрами системы, потенциалы межмолекулярного взаимодействия и т.п.). Совсем краем зацепил клеточные автоматы («Машины клеточных автоматов», автора не помню уже).
Потом был долгий период промавтматизации где математики практически нет. Но параллельно для себя занимался обработкой GPS данных. Там опять математика, в частности в задачах фильтрации GPS треков. Кстати, смотрю на многие мобильные приложения типа спортивных трекеров, работающих с GPS и понимаю, что разработчики вообще не понимают природы данных, которые они получают с чипа и в результате трекеры выдают редкостный бред на экран.
Сейчас вот работа с базами данных. Опять никакой математики, но, как и в промавтоматизации, требуется хорошее знание платформы на которой работаешь, ее возможностей и того, как наиболее эффективно использовать ресурсы.
В целом, дабы быть более-менее эффективным и универсальным разработчиком и не зацикливаться на какой-то узкой области типа рисования семи красных линий одной строчкой кода, математику желательно таки знать. Ну не на уровне д.ф.-м.н., но достаточно свободно ориентироваться, но обладать базой, дающей возможность при необходимости самостоятельно углубиться в нужную тему.
Мне в этом плане повезло — в свое время заканчивал физтех, а это полный курс математики (первые три года 200 часов лекций в семестр — матанализ, аналитическая геометрия, дифференуиальное исчисление, матстатистика, функции комплексных переменных, уравнения матфизики — все это отдельными курсами) плюс полный курс теорфизики по Ландау-Лифшицу плюс еще ряд физических курсов. В жизни не раз помогало в решении на первый взгляд не связанных напрямую с физикой или математикой задач.
Как-то длинно получилось, но такие вот мысли на тему с точки зрения разработчика с 30-летним стажем.
Вопрос оптимизации в работе встает постоянно. Вот уже не один десяток лет. Долгое время работал в области промавтоматизации — там приходится разрабатывать код, который должен работать быстро (а в большинстве случаев не просто быстро, а с гарантированным временем отклика), надежно и при этом в условиях ограниченных ресурсов (как по памяти, так и по быстродействию). там никто не даст менять оборудование на помощнее только потому, что разработчик не умеет вместо трех вложенных циклов сделать все за один проход. Проще разработчика поменять.
Сейчас занимаюсь разработкой под мейнфреймы. Казалось бы можно расслабиться — одной оперативки в разы больеше чем у многих на диске. Однако периодически сталкиваемся с тем, что пиковая нагрузка на сервера достигает 96-98% И кроме разработки нового приходится пересматривать старое в поисках где что можно оптимизировать.
Тут выручает привычка сразу искать оптимальное решение. И оно находится, если подумать чуть-чуть. Бывали случаи когда первое пришедшее в голову решение (в лоб) давало время выполнения задачи 3 сек (что для данной задачи было неприемлемым), а второе — 150-200 мсек.
Понятно, что всяких сайтописателей все это не волнует — ну и что с того, что сайт грузится медленно? Зато там «все красиво» и рекламы понапихали выше крыши — а это деньги.
У «мобильных разработчиков» из тех, которых заботит только вопрос монетизации своих поделий тоже всегда найдется отмазка — а что вы хотели на таком древнем девайсе?
Ну у вас хоть какая-то подготовка и креатив чувствуется. А мне дебилы какие-то звонят в надежде что вдруг у меня в сбере что-то есть. А нет и никогда не было. Т.е. просто по номеру телефона наудачу ломятся.
В последний раз обиделся и прямо посоветовал уроки учить получше.
Везет же людям… А мне все школота какая-то звонит. «Из Сбербанка» где у меня никогда не было ничего…
Можно конечно, поприкалываться, повеститьсь на разводку, сказать им пароль из смс, а потом «ой, извинте, у меня оказывается не сбер, а совсем другой банк...»
Позиции «отстающих» были заложены еще тогда. Поверьте на слово — родители всю жизнь в РАН, сам там начинал трудовую деятельность в конце 80-х
У жены родители в ВУзе всю жизнь проработали.
Так что что такое «советская наука» знаю из первых рук. Не была она передовой очень и очень давно уже.
С инструментами для разработки под платформы Apple сложнее — там очень много наследия из времён Objective-C, старого и неудобного системного API.
Вот пока разработчик досконально это самое «системное API» не изучит и не начнет понимать как оно там внутри все работает, нормального продукта от него трудно ждать.
«Нормальный» это прежде всего функциональность плюс стабильность при минимальных требованиях к ресурсам.
О господи… Вы бы хоть карту посмотрели для интереса.
Каким боком там Челябинск? ВУРС проходит примерно посередине между Челябинском и Екатеринбургом перпендикулярно трассе их соединяющей.
Там действительно есть длинный, но достаточно узкий «язык» от Озерска на восток. Но при этом сам Озерск, Касли, Кыштым он не затрагивает. В том же Карабаше (недалеко) экологическая ситуация и заболеваемость хуже в разы (если не на порядок) по совершенно иными причинам и безо всякой радиации.
Ну и чтобы два раза не вставать
Позже Мазин рассказал журналисту: «Я за ядерную энергию, я думаю, что ядерная энергия — необходимый элемент борьбы с глобальным потеплением». Потом он согласился с твитом о том, что «Чернобыль» не может произойти в США.
Угу. Только началось все с Тримайл Айленд. Первая, насколько помню, официально признанная крупная авария на АЭС.
Но сейчас там такого произойти не может, это точно. Последний энергоблок в США был введен в строй в 1979-м году. С тех пор ничего не построили. Попытка построить новую АЭС привела к банктроству основного подрядчика — Вестингауз и признанию того, что в США нет компании, которая способна самостоятельно построить корпус водно-водяного реактора (заказы размещаются в Южной Корее и Италии, потом еще куча приключений с перевозкой — история весьма занимательная).
Даже без брокерской деятельности нагрузка очень велика. Просто на обычных операциях.
А еще в банке баланс сводится каждый день. Так называемый EOD (End-Of-Day). А если АБС (Автоматизированная Банковская Система) работает в режиме реального времени, то там совсем весело — перед переходом в EOD создается т.н. «юнит ночного ввода» где продолжают идти все операции. А по окончании EOD производится «накат» — перенос всех изменений из ночного юнита в дневной (который уже перешел на следующий день). И попутно формируются различные отчеты и т.п.
А еще проверки операций для комплаенса, проверки пользователей на всякие риски и много-много чего.
В результате на сервере одновременно крутится огромное количество задач с конкурентным доступом к данным.
Любой сбой приводит к финансовым потерям и репутационным убыткам. В результате каждая новая задача проходит многоэтапное тестирование
1. Компонентное — на соответсвие ТЗ и отсутствие грубых ошибок, приводящих к падению задачи.
2. Бизнес — на соответствие заявки на разработку (т.е. это тест ТЗ + его реализации)
3. Интеграционное — на непротиворечивость взаимодействия со всеми остальными компонентами системы и отсутствия конфликтов в работе
4. Для регулярно запускаемых задач (те же отчеты, к примеру) еще обязательно нагрузочное тестирование — сколько ресурсов потребляет задача и насколько она оптимальна.
По факту казалось бы ничего сложного в разработке нет — обычная работа с БД. А на практике постоянная голована боль о том, чтобы каждую операцию пытаться сделать максимально эффективной. Не злоупотреблять «тяжелыми» операциями, по возможнсти вынося их из цикла. Там где можно сократить количество обращений к БД — кешировать все что можно. Задачи с большим количеством вычислений распараллеливать на мастера, выдающего задания и фиксирующего результаты и исполнителей (5-10 параллельных задач), обрабатывающих выданные блоки информации. Тут сразу встает вопрос эффективного межпроцессного взаимодействия (обмена данными) и контроля мастера за исполнителями… И т.д. и т.п.
Ну не совсем так. В банковских системах основная проблема в том, что часто приходится оперировать большими объемами данных (ну скажем, пройтись по нескольким десяткам миллионов записей в одной таблице, а для большинства записей подтянуть еще десяток из другой таблицы). Потом по полученным данным еще из третьей таблицы что-то выбрать, сопоставить то что есть с тем что должно быть и внести необходимые изменения. И все это должно сработать за некоторое разумное время (т.е не пол дня, а полчаса, например). И работает все это наряду с еще сотней задач. Т.е. оно не должно сильно грузить систему.
Т.е. все упирается в производительность и эффективность при работе с большими объемами данных, распределенных по нескольким местам. И далеко не всегда удается решить задачу в лоб, одним скулевым запросом. Была такая ситуация — проверка наличия строки в таблице. Но строки там хранятся группами в виде набора слов. Лобовое решение через listagg работает, но время примерно 2.5сек. А по ТЗ надо укладываться в 150-200мс. Вот и приходится мудрить с высокоселективными предвыборками, частотным словарем и т.д. и т.п.
Насчет системы сдерживания вопрос спорный. Взять хотя бы «Патриотический Акт», принятый в США после 9-11. Никаких «общественных институтов» дам и близко не подпустили. Просто приняли «из соображений госбезопасности».
Есть и другие примеры того, как госслужбы обходят любые институты когда им это выгодно — самый просто способ наложить гриф «Top Secret» мотивируя соображениями национальной безопасности.
Увы, но спецслужбы всегда и везде стремились, стремятся и будут стремиться получить возможность неограниченного контроля на всем до чего дотянутся. И противовесом может быть не общественный институт, а конкретные структуры с большими возможностями и полномочиями, потенциально страдающие от сих стремлений.
AS/400 плавно превратилась в IMB i И все еще живее всех живых. Просто не на каждом углу встречается в силу высокой стоимости — только у тех, кому настолько нужна производительность и надежность, что он готов за это платить
Вот уж воистину… Сейчас любой школьник, написавший пару учебных приложений на джаве, мнит себя нереальным гуру и раздает всем советы «космического масштаба космической же глупости» (с)
Упс. Лет двадцать с лихом в промавтоматизции проработал и ту такое…
Операционные системы реального времени (ОСРВ) – это операционные системы, способные обеспечить предсказуемое время обработки непредсказуемо возникающих внешних событий. Разделяют ОС «жесткого» и «мягкого» реального времени: для первых временные характеристики гарантированы, и выход за их пределы расценивается как отказ, для вторых временные ограничения, как правило, соблюдаются, и выход за их пределы считается снижением производительности.
Именно для этого они и разрабатывались. Чтобы ни происходило внутри системы, она должна отреагировать на поступление внешнего сигнала в течении заданного времени.
И какой бы вы приоритет не задавали UI потокам на андроиде, оно будет лагать если в это время андроиду запитимет память оптимизировать. Мы же знаем, что при «закрытии» приложения на андроиде физически оно из памяти не выгружается (что они курили когда такую фигню придумывали?) до тех пор пока системе не потребуется больше памяти и она не начнет ревизию что сейчас можно выгрузить.
Ну еще сборщик мусора javaмашины может активироваться и тормознуть систему.
Всему этому глубоко по барабану какие у вас там приоритеты для UI стоят.
Ну и еще один аспект. Бывает что программист работает по ТЗ. Где написано «возьми то и положи туда». Это работа не разработчика а кодировщика. Тут действительно ничего особо знать не нужно кроме как нарисовать семь красных линий одной строкой кода.
А бывает что разработчику дается полноценное FSD — «на входе имеем то, на выходе нужно получить это». А выбор алгоритма и его реализации уже полностью на совести разработчика. И очень часто необходимость разработки нового возникает потому что ни один из 100500 существующих продуктов не устраивает по каким-то критериям. А это значит, что нужно придумывать что-то новое, а не то что выдается гуглем в первых пяти строках поиска.
Впрочем, это отдельная тема про различия разработчика и кодировщика.
При катании на лыжах ситуация радикально иная. Во-первых, лыжник все-таки движется дугами т.е. постоянно меняет направление. Во-вторых, прибор обычно лежит в кармане где-то в верхней половине корпуса. Т.е. при перекантовках и смене ангуляции прибор вместе с корпусом совершает резкое движение перпендикулярно траектории.
Все это резко повышает погрешность измерения скорости и в максималку может попасть не скорость лыжника, а вот эта скорость самого прибора в момент перекантовки.
Я накопил достаточно большую коллекцию треков, записанных логгером (он тупо пишет nmea поток с чипа с частотой 5 точек в секунду на карту памяти). Просмотр таких треков по точкам показывает кратковременные рывки скорости именно в такие моменты, как указано выше.
Методика спидсерферов такая — в зачет идет усредненная на 5-10 секунд скорость на прямолинейном отрезке. Это более адекватный параметр. Возможно, там еще отбрасываются «хвосты» по правилу трех сигм. У них есть специальный софт для анализа треков и участники просто присылают свои треки, а результаты уже выдаются софтом.
У мобильных приложений далеко не у всех заложена хоть какая-то фильтрация. Многие выводят напрямую то, что прилетело с чипа.
Я далеко не все смотрел, из точно фильтрующих видел meRun (для андроида, для Blackberry пользуюсь ей же, там называется CascaRun). Правда, описания алгоритма фильтрации не знаю. Но какие-то настройки фильтров там есть.
Для компа сам писал анализатор треков. Там много всяких фильтров для прочистки треков и удаления недостоверных (в т.ч. и по скорости) точек и подсчета статистики.
А если потребуется еще и маршруты строить, то тут теория графов в полный рост…
Так что или не зарекаться что никогда не понадобиться, или заранее исключить для себя определенные области разработки.
Так что более чем понимаю такое решение :-)
Правда, я равнодушен к визуальным финтифлюшкам, не люблю писать интерфейсы, люблю глубокий backend и получаю удовольствие от отладки системным отладчиком в зеленом экране (эмулятор терминала IBM5250)
Есть мобильные приложения — спортвные трекеры. Например, катаемся на горных лыжах, на телефоне запущено такое приложение. По итогу оно нам показывает суммарный набор-потерю высоты, сколько по расстоянию накатали, максимальную скорость на спуске. Так вот периодически люди (обычно новички) в профильных форумах начинают хватстаться что у них где-то там максимальная скорость была аж 120км/ч (порядок величин такой). при том, что такая скорость характерна для спортсменов на соревнованиях по скоростному спуску на этапах КМ. Но те-то едут в обтекаемых комбезах в низкой аэродинамической стойке на 2+ м спусковых лыжах и по очень жесткой трассе. Для любителя в куртке и широких штанах на обычных лыжах такое в принципе недостижимо.
Да, такая цифра может придти с чипа, но надо понимать откуда она взялась и как соотносится с реальностью. На тему измерения скорости с помощью GPS написано много статей с разбором в каких ситуациях какая погрешность возможна. Есть сообщество спидсерферов (speedsurfing), которые измеряют скорость с помощью GPS и сравнивают ее с другими — у них разработаны методики записи и обработки треков для получения адекватных сравнимых величин.
Но во все это надо вникать, разбираться. А в мобильную разработку пришло огромное количество… даже не знаю как назвать… людей, которые больше озабочены проблемами монетизации, чем реальной полезностью своей разработки.
Второй пример, с теми же трекерами. Велсипед. Человек покатался по парку (условно) и хвастается что у него суммарный набор высоты аж полтора километра. Ага. На 30-50 километров пути. Родной, откуда? Ты в Альпах через перевалы катался?
Опять нужно понимать, что точность определения высоты в силу физики процесса в GPS на порядок ниже точности определения координат. И в отсутствии барометрического альтиметра в приборе высота даже стоя на месте будет «плавать» и накручивать «суммарный набор». А при наличии оного его нужно регулярно калибровать.
Кроме того, суммарный набор неплохо накручиватеся на мелких кочках. Метр туда, метр сюда, глядишь и полтора километра набежало.
Все это нужно фильтровать и указывать что набрал столько-то при таких-то настройках (скажем, не учитывал наборы на уклонах меньше одного градуса, не учитывал единичные перепады менее полутора метров и т.п.)
Это как раз не удивительно. Физика суть наука описательная. И в ней главное понимать как оно все между собой взаимодействует на некотором интуитивном уровне, чем уметь на каждый случай написать формулу для получения нужного ответа.
Есть у меня знакомый, занимается репетиторством по физике. Так вот у него методика сторится на том, что сналала все описывается «на пальцах», без формул. Затем вводятся понятия «базовых величин» (расстояние, время, температура, масса...) Затем переход от базовых к величинам производным (как из рассотяния и времени получить скорость и т.п.). А затем уже то, что описано на пальцах описывается формулами.
Когда он эту методику начал применять на практике, то был сам поражен насколько быстро те, кому физика в школе ну совсем никак не лезет в голову, начинали понимать ее суть и прогрессировать.
Общий посыл такой — загрузить под завязку можно любую систему. И чем меньше думать об оптимальности кода при разработке, тем быстрее этот момент наступит. Заниматься переоптимизацией того, что уже работает намного сложнее хотя бы потому, что каждое изменение кода требует потом длительной серии ретестов на неухудшение функциональности.
Поменять железо на помощнее (любимая отмазка плохих разработчиков — «тормозит потому что железо слабое, проапгрейдитесь и все будет ок») не вариант — затраты (даже не считая стоимости самого железа в несколько сотен килобаксов) по переносу всего и вся на новые железяки космические.
Простейший пример с прошлой работы. Была задача по разработке системы мониторинга инженерного оборудования зданий. В качестве одного из конкретных применений — система ЛДСС (лифтовая диспетчерская связь и сигнализация). Так вот, есть ПУБЭЛ (правила установки и безопасной эксплуатации лифтов), согласно которым лифт не имеет права работать без работающей системы ЛДСС. Это значит, что если вы захотите на работающем объекте переустановить (скажем, поставить новую версию) систему, то сначала вы должны отключить все лифты к ней подключенные. Т.е. физически их остановить и заблокировать. А в современных версиях их может быть несколько сотен (штук 300 даже на одной не очень большой диспетчерской). И раскиданы они по всему городу (связь идет по IP каналам). И далеко не все модели могут быть остановлены и заблокированы дистеанционно. Представляете ситуацию — бригады аварийщиков носятся по городу и останавливают лифты просто потому что вам запотимело совтину поменять?
Здесь все еще серьезнее. На порядки.
Масштабы страны во-первых, во-вторых останавливать нельзя. только вводить параллельно, потом убедиться что все работает и только потом выводить старое.
Так что единственный вариант — сразу писать оптимальный код. Для особо критических задач проводить нагрузочное тестирование (это кроме компонентного, интеграционного и бизнес).
Так что над каждой задачей приходится думать. И каждое решение переосмысливать — а можно ли написать оптимальнее? А как можно скроить на количестве ресурсоемких операций? Что вынести в инициализацию чтобы выполнялось один раз, а что придется делать на каждом обороте цикла? Как оптимально распределить функции между master`ом и worker`ами при распараллеливании обработки и как эффективно организовать межпроцессную коммуникацию.
Это то, что касается оптимизации.
Собственно по математике. Достаточно много задач, где математика особо и не нужна. А есть где нужна. На совей спрактике когда-то давно приходилось заниматься разработкой программ для обработки экспериментальных данных. Там использовались методы регрессионного анализа (в те времена книга Грейпера и Смита «Прикладной регрессионный анализ» была настольной). Потом немного коснулся темы молекулярной динамики и машинного моделирования (там и физика — статфизика и математика: микро- и макроканонические ансамбли, связь между функцией распределения параметров отдельных молекул с макропараметрами системы, потенциалы межмолекулярного взаимодействия и т.п.). Совсем краем зацепил клеточные автоматы («Машины клеточных автоматов», автора не помню уже).
Потом был долгий период промавтматизации где математики практически нет. Но параллельно для себя занимался обработкой GPS данных. Там опять математика, в частности в задачах фильтрации GPS треков. Кстати, смотрю на многие мобильные приложения типа спортивных трекеров, работающих с GPS и понимаю, что разработчики вообще не понимают природы данных, которые они получают с чипа и в результате трекеры выдают редкостный бред на экран.
Сейчас вот работа с базами данных. Опять никакой математики, но, как и в промавтоматизации, требуется хорошее знание платформы на которой работаешь, ее возможностей и того, как наиболее эффективно использовать ресурсы.
В целом, дабы быть более-менее эффективным и универсальным разработчиком и не зацикливаться на какой-то узкой области типа рисования семи красных линий одной строчкой кода, математику желательно таки знать. Ну не на уровне д.ф.-м.н., но достаточно свободно ориентироваться, но обладать базой, дающей возможность при необходимости самостоятельно углубиться в нужную тему.
Мне в этом плане повезло — в свое время заканчивал физтех, а это полный курс математики (первые три года 200 часов лекций в семестр — матанализ, аналитическая геометрия, дифференуиальное исчисление, матстатистика, функции комплексных переменных, уравнения матфизики — все это отдельными курсами) плюс полный курс теорфизики по Ландау-Лифшицу плюс еще ряд физических курсов. В жизни не раз помогало в решении на первый взгляд не связанных напрямую с физикой или математикой задач.
Как-то длинно получилось, но такие вот мысли на тему с точки зрения разработчика с 30-летним стажем.
Сейчас занимаюсь разработкой под мейнфреймы. Казалось бы можно расслабиться — одной оперативки в разы больеше чем у многих на диске. Однако периодически сталкиваемся с тем, что пиковая нагрузка на сервера достигает 96-98% И кроме разработки нового приходится пересматривать старое в поисках где что можно оптимизировать.
Тут выручает привычка сразу искать оптимальное решение. И оно находится, если подумать чуть-чуть. Бывали случаи когда первое пришедшее в голову решение (в лоб) давало время выполнения задачи 3 сек (что для данной задачи было неприемлемым), а второе — 150-200 мсек.
Понятно, что всяких сайтописателей все это не волнует — ну и что с того, что сайт грузится медленно? Зато там «все красиво» и рекламы понапихали выше крыши — а это деньги.
У «мобильных разработчиков» из тех, которых заботит только вопрос монетизации своих поделий тоже всегда найдется отмазка — а что вы хотели на таком древнем девайсе?
В последний раз обиделся и прямо посоветовал уроки учить получше.
Можно конечно, поприкалываться, повеститьсь на разводку, сказать им пароль из смс, а потом «ой, извинте, у меня оказывается не сбер, а совсем другой банк...»
У жены родители в ВУзе всю жизнь проработали.
Так что что такое «советская наука» знаю из первых рук. Не была она передовой очень и очень давно уже.
Вот пока разработчик досконально это самое «системное API» не изучит и не начнет понимать как оно там внутри все работает, нормального продукта от него трудно ждать.
«Нормальный» это прежде всего функциональность плюс стабильность при минимальных требованиях к ресурсам.
Каким боком там Челябинск? ВУРС проходит примерно посередине между Челябинском и Екатеринбургом перпендикулярно трассе их соединяющей.
Там действительно есть длинный, но достаточно узкий «язык» от Озерска на восток. Но при этом сам Озерск, Касли, Кыштым он не затрагивает. В том же Карабаше (недалеко) экологическая ситуация и заболеваемость хуже в разы (если не на порядок) по совершенно иными причинам и безо всякой радиации.
Ну и чтобы два раза не вставать
Угу. Только началось все с Тримайл Айленд. Первая, насколько помню, официально признанная крупная авария на АЭС.
Но сейчас там такого произойти не может, это точно. Последний энергоблок в США был введен в строй в 1979-м году. С тех пор ничего не построили. Попытка построить новую АЭС привела к банктроству основного подрядчика — Вестингауз и признанию того, что в США нет компании, которая способна самостоятельно построить корпус водно-водяного реактора (заказы размещаются в Южной Корее и Италии, потом еще куча приключений с перевозкой — история весьма занимательная).
А еще в банке баланс сводится каждый день. Так называемый EOD (End-Of-Day). А если АБС (Автоматизированная Банковская Система) работает в режиме реального времени, то там совсем весело — перед переходом в EOD создается т.н. «юнит ночного ввода» где продолжают идти все операции. А по окончании EOD производится «накат» — перенос всех изменений из ночного юнита в дневной (который уже перешел на следующий день). И попутно формируются различные отчеты и т.п.
А еще проверки операций для комплаенса, проверки пользователей на всякие риски и много-много чего.
В результате на сервере одновременно крутится огромное количество задач с конкурентным доступом к данным.
Любой сбой приводит к финансовым потерям и репутационным убыткам. В результате каждая новая задача проходит многоэтапное тестирование
1. Компонентное — на соответсвие ТЗ и отсутствие грубых ошибок, приводящих к падению задачи.
2. Бизнес — на соответствие заявки на разработку (т.е. это тест ТЗ + его реализации)
3. Интеграционное — на непротиворечивость взаимодействия со всеми остальными компонентами системы и отсутствия конфликтов в работе
4. Для регулярно запускаемых задач (те же отчеты, к примеру) еще обязательно нагрузочное тестирование — сколько ресурсов потребляет задача и насколько она оптимальна.
По факту казалось бы ничего сложного в разработке нет — обычная работа с БД. А на практике постоянная голована боль о том, чтобы каждую операцию пытаться сделать максимально эффективной. Не злоупотреблять «тяжелыми» операциями, по возможнсти вынося их из цикла. Там где можно сократить количество обращений к БД — кешировать все что можно. Задачи с большим количеством вычислений распараллеливать на мастера, выдающего задания и фиксирующего результаты и исполнителей (5-10 параллельных задач), обрабатывающих выданные блоки информации. Тут сразу встает вопрос эффективного межпроцессного взаимодействия (обмена данными) и контроля мастера за исполнителями… И т.д. и т.п.
Так что скучать не приходится :-)
Т.е. все упирается в производительность и эффективность при работе с большими объемами данных, распределенных по нескольким местам. И далеко не всегда удается решить задачу в лоб, одним скулевым запросом. Была такая ситуация — проверка наличия строки в таблице. Но строки там хранятся группами в виде набора слов. Лобовое решение через listagg работает, но время примерно 2.5сек. А по ТЗ надо укладываться в 150-200мс. Вот и приходится мудрить с высокоселективными предвыборками, частотным словарем и т.д. и т.п.
Есть и другие примеры того, как госслужбы обходят любые институты когда им это выгодно — самый просто способ наложить гриф «Top Secret» мотивируя соображениями национальной безопасности.
Увы, но спецслужбы всегда и везде стремились, стремятся и будут стремиться получить возможность неограниченного контроля на всем до чего дотянутся. И противовесом может быть не общественный институт, а конкретные структуры с большими возможностями и полномочиями, потенциально страдающие от сих стремлений.
Увы, как бы это ни было цинично, но это так.
https://embedded.prosoft.ru/tags/osrv/
Именно для этого они и разрабатывались. Чтобы ни происходило внутри системы, она должна отреагировать на поступление внешнего сигнала в течении заданного времени.
И какой бы вы приоритет не задавали UI потокам на андроиде, оно будет лагать если в это время андроиду запитимет память оптимизировать. Мы же знаем, что при «закрытии» приложения на андроиде физически оно из памяти не выгружается (что они курили когда такую фигню придумывали?) до тех пор пока системе не потребуется больше памяти и она не начнет ревизию что сейчас можно выгрузить.
Ну еще сборщик мусора javaмашины может активироваться и тормознуть систему.
Всему этому глубоко по барабану какие у вас там приоритеты для UI стоят.