А вот интересно два момента
1. Оборудование на узлах маршрутизации чье? И кто гарантирует отсутствие в нем закладок, позволяющих превратить в кирпич все внутренние маршрутизаторы суверенного рунета?
Это как бы с одной строны посмотреть.
С другой стороны взгляд
2. Кто из отметившихся тут комментаторов занимался разработкой в области распределенных систем, так или иначе связанных с обеспечением жизнедеятельности? Ну скажем, управление большими энергосистемами, хотя бы на уровне МРСК. Какими мерами вы обеспечиваете надежность функционирования системы в случае проблем с маршрутизацией?
Честно говоря, больше волнует это, а не возможность смотреть порнокотиков или читать откровения очередного либерального блоггера.
Что касается получения информации — жизнь всегда найдет лазейку. И в кровавом совке вражьи голоса сквозь глушилки слушали и во время путчей 90-х годов информация в регионы летала помимо официальных каналов (а рунет тогда был в зачаточом состоянии).
Для власти самое страшное — потерять иллюзию своей легитимности и выборности. По крайней мере пока это так.
Посему, избирателей на выборы заманивают всеми возможными способами.
Ваш пример не является показательным. Для линейной регрессии есть прямые формулы без матричной арифметики.
А вот когда параметров станет 7-10 и более, то градиентный спуск для функции [среднеквадратичного отклонения] многих переменных может стать весьма ресурсозатратным.
А если еще выбранная модель будет нелинейной по параметрам, то станет совсем весело — появляется риск попасть на локальный минимум.
В общем случае регрессия сводится к решению задачи по оптимизации — нахождению экстремума функции. Линейной или нелинейной относительно параметров. И одним градиентным спуском там не ограничивается.
В общем, советую поискать серьезную литературу на эту тему — учебники, лекции. Может быть еще будет полезно поискать по теме «обработка экспериментальных данных». Там и статистический и регрессионный анализ используется.
Очень и очень поверхностно.
Рекомендую почитать Весьма доходчиво написано. Хотя и «много буков».
На самом деле, тема намного сложнее чем тут описано. Все сказанное выше хорошо и справедливо в том случае, когда есть данные и есть готовая модель (уравнение), которая их описывает и вопрос только в том, чтобы найти коэффициенты этой модели.
Но модели может и не быть как таковой. И типичная ситуация такова — вот вам результат и вот вам десяток факторов, которые могут на него влиять. А могут и не влиять. И для начала нужно определить что влияет на результат, а что нет — какие факторы нужно учитывать при построении модели, а какие можно отбросить. Это и есть регрессионный анализ.
Я вообще-то употребил термин «разработчик». Человек, разрабатывающий некий конечный продукт.
Естественно хорошего алгоритма нет — откуда ему взяться, когда у вас даже надёжной формализации «целенаправленного движения» нет?
Правильно. Сначала нужно проанализировать куеву хучу треков чтобы понять по каким признакам выделять участки направленного движения, а по каким участки дрифта.
И это тоже работа для разработчика в общем смысле. Да, бывают ситуации, когда эту часть на себя берет аналитик. А бывает когда нет.
А потом еще прогнать эту кучу треков через тесты чтобы понять насколько оно получилось работоспособно. Может быть тут тестировщик поможет. А может и нет.
Если вы не понимаете, что бизнес-задача, описанная обычным языком — это тоже вполне себе ТЗ — то ой.
«Ой» — это если вы не представляете себе что при решении таких задач может потребоваться что-то сложнее правильно составленного запроса в гугл и скачивания готовой формулы.
В том и дело, что я видел на треках нереальные скорости и не на прямых.
А с высотой — да. В силу особенностей технологии точность ее определения сильно хуже точности определений координат. Тут спасает наличие барометрического альтиметра, но его нужно калибровать каждый раз перед использованием и он может вносить погрешность при резких изменениях давления (когда погода меняется резко и сильно).
Если не нужны абсолютные значения высоты, а просто оценка относительных разностей я обычно заменяю высоты, определенные прибором на высоты из SRTM таблиц (они доступны в сети) по координатам. Там тоже погрешность, но, по крайней мере если через час пришел на ту точку, где уже был, высота будет та же самая :-)
Ну или более сложные алгоритмы с усреднением высот в одинаковых точках, коррекция высоты прибора с привлечением высот из таблицы (с эвристикой какая из высот точнее) и т.п. Но тут опять математика, которая «не нужна» и без которой «можно замечательно обойтись потому что все уже до на придумано» :-)
В любом ТЗ написано «возьми то и положи туда» (да и задачи в вольной постановке тоже формулируются именно таким образом). Разница только лишь в объеме пропущенных шагов.
Хорошо когда так. А когда «ТЗ» формулируется в виде «нам нужно разработать систему, которая позволит управляющей компании, обслуживающей объекты по всему городу и в города-спутниках, держать всего одну диспетчерскую куда сходятся все сигналы со всех объектов, представляются в наглядном виде, логируются и т.д. и т.п.». В команде есть координатор, есть схемотехник, есть разрабочик под микроконтроллеры и два разработчика на верхний уровень.
Да, тут нет математики. Это просто пример из реальной практики когда ТЗ как такового нет. Есть бизнес-задача которую надо решить. Дальше строится архитектурное решение, разрабатываются протоколы обмена данными, выделяются логические блоки и дальше каждый уже в рамках своего блока ищет наиболее оптимальное решение.
И любая задача решается именно так. просто где-то есть аналитик, которрый решает вопросы с бизнесом и превращает их хотелки в FSD той или иной степени подробности для разработчика.
А где-то аналитика нет и разработчику приходится начинать разработку с чистого листа — выбора архитектуры построения системы. И далее по списку.
Вторая задача из личной практики. Нужно отфильтровать «дрифты» в GPS треках с минимальной потерей данных. Дрифт — это ситуация когда прибор неподвижен, а координаты точки «гуляют» в результате чего трек выглядит как будто прибор хаотично перемещали туда-сюда во все стороны с амплитудой, доходящей до нескольких десятков метров. Дополнительное условие — нужно максимально точно отслеживать момент как остановки, так и начала целенаправленного движения.
Никаких указаний как это можно сделать от заказчика, естественно, не поступило. Просто хотелка — удалить.
Гугль выдает обескураживающие результаты — более-менее надежного алгоритма нет. Нужно изобретать самому. Тут уже без математики туго.
Я не делю задачи по сложности. Я делю их по степени подготовки для кодирования (которое является конечным этапом любой разработки). И на практике приходилось сталкиваться с очень широким спектром от ТЗ в стиле «сделайте мне красиво» до полностью прописанного алгоритма, который остается только выразить в виде собирающегося кода.
Для решения конкретно вашей задачи давно уже существует 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 мсек.
Понятно, что всяких сайтописателей все это не волнует — ну и что с того, что сайт грузится медленно? Зато там «все красиво» и рекламы понапихали выше крыши — а это деньги.
У «мобильных разработчиков» из тех, которых заботит только вопрос монетизации своих поделий тоже всегда найдется отмазка — а что вы хотели на таком древнем девайсе?
Ну у вас хоть какая-то подготовка и креатив чувствуется. А мне дебилы какие-то звонят в надежде что вдруг у меня в сбере что-то есть. А нет и никогда не было. Т.е. просто по номеру телефона наудачу ломятся.
В последний раз обиделся и прямо посоветовал уроки учить получше.
Везет же людям… А мне все школота какая-то звонит. «Из Сбербанка» где у меня никогда не было ничего…
Можно конечно, поприкалываться, повеститьсь на разводку, сказать им пароль из смс, а потом «ой, извинте, у меня оказывается не сбер, а совсем другой банк...»
1. Оборудование на узлах маршрутизации чье? И кто гарантирует отсутствие в нем закладок, позволяющих превратить в кирпич все внутренние маршрутизаторы суверенного рунета?
Это как бы с одной строны посмотреть.
С другой стороны взгляд
2. Кто из отметившихся тут комментаторов занимался разработкой в области распределенных систем, так или иначе связанных с обеспечением жизнедеятельности? Ну скажем, управление большими энергосистемами, хотя бы на уровне МРСК. Какими мерами вы обеспечиваете надежность функционирования системы в случае проблем с маршрутизацией?
Честно говоря, больше волнует это, а не возможность смотреть порнокотиков или читать откровения очередного либерального блоггера.
Что касается получения информации — жизнь всегда найдет лазейку. И в кровавом совке вражьи голоса сквозь глушилки слушали и во время путчей 90-х годов информация в регионы летала помимо официальных каналов (а рунет тогда был в зачаточом состоянии).
Посему, избирателей на выборы заманивают всеми возможными способами.
А вот когда параметров станет 7-10 и более, то градиентный спуск для функции [среднеквадратичного отклонения] многих переменных может стать весьма ресурсозатратным.
А если еще выбранная модель будет нелинейной по параметрам, то станет совсем весело — появляется риск попасть на локальный минимум.
www.sociologos.ru/metody_i_tehnologii/Razdel_Analiz_dannyh/Regressionnyj_analiz_i_korrelyaciya/Prikladnoj_regressionnyj_analiz_Drejper_Smit
Дрейпер, Смит. Прикладной регрессионный анализ.
Одно время была настольной книгой.
В общем случае регрессия сводится к решению задачи по оптимизации — нахождению экстремума функции. Линейной или нелинейной относительно параметров. И одним градиентным спуском там не ограничивается.
В общем, советую поискать серьезную литературу на эту тему — учебники, лекции. Может быть еще будет полезно поискать по теме «обработка экспериментальных данных». Там и статистический и регрессионный анализ используется.
Рекомендую почитать Весьма доходчиво написано. Хотя и «много буков».
На самом деле, тема намного сложнее чем тут описано. Все сказанное выше хорошо и справедливо в том случае, когда есть данные и есть готовая модель (уравнение), которая их описывает и вопрос только в том, чтобы найти коэффициенты этой модели.
Но модели может и не быть как таковой. И типичная ситуация такова — вот вам результат и вот вам десяток факторов, которые могут на него влиять. А могут и не влиять. И для начала нужно определить что влияет на результат, а что нет — какие факторы нужно учитывать при построении модели, а какие можно отбросить. Это и есть регрессионный анализ.
Правильно. Сначала нужно проанализировать куеву хучу треков чтобы понять по каким признакам выделять участки направленного движения, а по каким участки дрифта.
И это тоже работа для разработчика в общем смысле. Да, бывают ситуации, когда эту часть на себя берет аналитик. А бывает когда нет.
А потом еще прогнать эту кучу треков через тесты чтобы понять насколько оно получилось работоспособно. Может быть тут тестировщик поможет. А может и нет.
«Ой» — это если вы не представляете себе что при решении таких задач может потребоваться что-то сложнее правильно составленного запроса в гугл и скачивания готовой формулы.
А с высотой — да. В силу особенностей технологии точность ее определения сильно хуже точности определений координат. Тут спасает наличие барометрического альтиметра, но его нужно калибровать каждый раз перед использованием и он может вносить погрешность при резких изменениях давления (когда погода меняется резко и сильно).
Если не нужны абсолютные значения высоты, а просто оценка относительных разностей я обычно заменяю высоты, определенные прибором на высоты из SRTM таблиц (они доступны в сети) по координатам. Там тоже погрешность, но, по крайней мере если через час пришел на ту точку, где уже был, высота будет та же самая :-)
Ну или более сложные алгоритмы с усреднением высот в одинаковых точках, коррекция высоты прибора с привлечением высот из таблицы (с эвристикой какая из высот точнее) и т.п. Но тут опять математика, которая «не нужна» и без которой «можно замечательно обойтись потому что все уже до на придумано» :-)
Хорошо когда так. А когда «ТЗ» формулируется в виде «нам нужно разработать систему, которая позволит управляющей компании, обслуживающей объекты по всему городу и в города-спутниках, держать всего одну диспетчерскую куда сходятся все сигналы со всех объектов, представляются в наглядном виде, логируются и т.д. и т.п.». В команде есть координатор, есть схемотехник, есть разрабочик под микроконтроллеры и два разработчика на верхний уровень.
Да, тут нет математики. Это просто пример из реальной практики когда ТЗ как такового нет. Есть бизнес-задача которую надо решить. Дальше строится архитектурное решение, разрабатываются протоколы обмена данными, выделяются логические блоки и дальше каждый уже в рамках своего блока ищет наиболее оптимальное решение.
И любая задача решается именно так. просто где-то есть аналитик, которрый решает вопросы с бизнесом и превращает их хотелки в FSD той или иной степени подробности для разработчика.
А где-то аналитика нет и разработчику приходится начинать разработку с чистого листа — выбора архитектуры построения системы. И далее по списку.
Вторая задача из личной практики. Нужно отфильтровать «дрифты» в GPS треках с минимальной потерей данных. Дрифт — это ситуация когда прибор неподвижен, а координаты точки «гуляют» в результате чего трек выглядит как будто прибор хаотично перемещали туда-сюда во все стороны с амплитудой, доходящей до нескольких десятков метров. Дополнительное условие — нужно максимально точно отслеживать момент как остановки, так и начала целенаправленного движения.
Никаких указаний как это можно сделать от заказчика, естественно, не поступило. Просто хотелка — удалить.
Гугль выдает обескураживающие результаты — более-менее надежного алгоритма нет. Нужно изобретать самому. Тут уже без математики туго.
Я не делю задачи по сложности. Я делю их по степени подготовки для кодирования (которое является конечным этапом любой разработки). И на практике приходилось сталкиваться с очень широким спектром от ТЗ в стиле «сделайте мне красиво» до полностью прописанного алгоритма, который остается только выразить в виде собирающегося кода.
Ну и еще один аспект. Бывает что программист работает по ТЗ. Где написано «возьми то и положи туда». Это работа не разработчика а кодировщика. Тут действительно ничего особо знать не нужно кроме как нарисовать семь красных линий одной строкой кода.
А бывает что разработчику дается полноценное 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 мсек.
Понятно, что всяких сайтописателей все это не волнует — ну и что с того, что сайт грузится медленно? Зато там «все красиво» и рекламы понапихали выше крыши — а это деньги.
У «мобильных разработчиков» из тех, которых заботит только вопрос монетизации своих поделий тоже всегда найдется отмазка — а что вы хотели на таком древнем девайсе?
В последний раз обиделся и прямо посоветовал уроки учить получше.
Можно конечно, поприкалываться, повеститьсь на разводку, сказать им пароль из смс, а потом «ой, извинте, у меня оказывается не сбер, а совсем другой банк...»