Все верно. Центр масс это не константная точка на автомобиле. Она смещается в зависимости от веса пассажиров и груза, а также их расположения в кабине и кузове. Но опять же для простоты центр масс (или тяжести) автомобиля указывается для стоящего на ровной горизонтальной поверхности нормально снаряженного автомобиля. Интересная публикация на Драйв2 про ручной расчет координат центра тяжести https://www.drive2.ru/l/522055268767367302/.
Здесь основная идея в том, что идеально правильный пробег автомобиля с точки зрения физики - это путь его центра масс в пространстве, где путь - это общая длина траектории этой точки. На счет геометрического центра соглашусь, наверное, это более корректное и оптимальное решение. Спасибо!
На самом деле, оба значения и пробег, и моточасы важны для учета технического обслуживания. Например, нет смысла вести регламент замены шин по моточасам у спецтехники, которая основную полезную работу делает, стоя на месте. Но на гражданских автомобилях для всех ТО используется именно пробег, потому что так проще, хотя силовой агрегат все-таки стоило бы обслуживать по моточасам.
И да, связь условная. Блок управления современного автомобиля хоть и пытается снизить погрешность в расчете реального пробега, но он не ведет учет износа расходников и агрегатов напрямую.
BMW и VAG в этом плане очень развиты, все видели их гирлянды на приборках, когда кончилась омывайка и перегорела левая фара. Но даже у них по большей части контроль выполняется на уровне "вышел из строя" / "работает в штатном режиме".
Кто владеет роботом-пылесосом, там есть раздел "расходники", где в процентах указан износ щеток, барабана и так далее. Этот износ в процентах всего лишь доля оставшегося заранее прописанного максимального пробега каждого расходника до замены. И если его вытащить и вставить обратно, нажав в приложении нужную кнопку, то мы просто сбросим оставшийся пробег до 100%.
Все верно! Напоминаю, что это лишь первая часть цикла статей. Я решил не "пихать" все в одну. Поэтому сейчас введение как первая статья кажется "ни о чем и обо всем".
Как я и писал, применение здесь очень узкое - показать пользователю, что нет идеальных способов расчета пробега ТС. В частности, извечная война: значение одометра на приборке автомобиля против рассчитанного пробега по ГНСС в программе. Клиент приходит с вполне логичным вопросом: "А чему верить?".
Это целый класс ПО - системы мониторинга транспорта (СМТ). И нет, это не очередная реклама такого сервиса, хотя я и являюсь основателем и разработчиком одной из таких ;) И нет, я не буду петь дифирамбы своей СМТ - статьи про другое.
Заголовок не соответствует содержимому: "Цифровая трансформация в логистике". Цифровой трансформации здесь нет, только интеграция программного решения и автоматизация отчетности по движению ГСМ на основе данных с навигационного терминала и датчика уровня топлива. И это не логистика, это обычный мониторинг транспорта. Логистика решает вопросы планирования и маршрутизации (будущее), мониторинг - наблюдения в реальном времени (сейчас) и работу с историческими данными (прошлое): отчеты, сводки, дашборды. Тема очень интересная, но, к сожалению, в статье все очень поверхностно.
PostgreSQL прекрасно умеет делать модификацию значений перечислений без необходимости промежуточных "махинаций", и уже довольно давно https://www.postgresql.org/docs/current/sql-altertype.html. Неужели в MySQL это не так, что-то сомневаюсь. Честно говоря, статья притянута за уши.
Первое же предложение "Часто разработчики интересуются почему не рекомендуется использовать тип поля enum в базе данных" намекает на какую-то надуманность, т.к. за 15 лет ни разу не слышал подобной постановки вопроса о ENUM в БД.
А вся статья себя по итогу оправдывает тем, что разработчики выкатили на прод в базу кривое значение в enum: "Через какое-то время была замечена грамматическая ошибка в слове "racing" и принято решение её исправить."
Так замеры не делаются. Нужно срочно все перевести на JMH (https://github.com/openjdk/jmh) с прогревом JVM и прогоном в минимум 10 раз с выведением средних результатов. Нельзя утверждать о каких-то сравнениях, не предоставив информацию о входных данных (размер входного файла, характеристики железа, сборка и версия JDK и так далее).
Ну и в дополнение к цитате Joshua Bloch, Шипилёв говорил, что знает только пару кейсов, когда можно использовать LinkedList вместо ArrayList, но даже тогда выигрыш настолько несущественный, что проще всегда использовать ArrayList ;)
Согласен. Платить приходиться через схемы. Постоянно прилетают письма про отказ от поддержки, уход от обслуживания и так далее. А пользоваться бесплатной версией просто страшно, т.к. в любой момент могут удалить без предупреждения. И это касается всех Atlassian продуктов.
Мы в итоге развернули себе GitLab CE. После JIRA, конечно, жесть как неудобно, зато теперь не нужно платить и все риски, связанные с политикой решены. Главное, бэкапы делать постоянно на внешний сервер :)
У нас в компании своя разработка. Написанный телематический сервер, который поддерживает тысячи разных девайсов от десятка производителетей. В рамках различных протоколов (открытых и проприетарных) поддерживается порядка 500 пунктов, которые можно получить с самого терминала, плюс переферийные датчики, входы/выходы цифровые, аналоговые, импульсные, чтение с CAN, BLE, датчики нагрузки, акселерометры и так далее. Дискретность данных порядка 5 записей в минуту (можно увеличить, если требуется). В итоге "в сухом остатке на диске" на 1 ТС, для которой выкрутили получение всего и вся, уходит максимум несколько десятков мегабайт в сутки.
У нас 25 гигов в час не получается набрать, даже если мы передаем видео с камер кругого обзора в 360 в реальном времени. Насколько надо написать неоптимально протокол и выбрать движок хранения данных, чтобы получить 600 Гигабайт в сутки с 1 ТС.
Раньше docker-compose (через тире) был отдельной утилитой, которую как бинарник отдельно качали и делали симлинк на каталог бинарников. Сейчас docker compose (без тире), начиная с версии 2.0, входит в стандартный пакет докера и ставить отдельно его не надо. По сути все тоже самое, поменяли просто API обращения к Docker Compose в CLI.
По поводу ошибки маппинга портов, уверен на 99%, что проблема в отступах в yaml файле, в статье все съехало. Должно быть так:
Автор, спасибо за интересную статью! Особенно круто, когда гос.проекты позволяют делиться подробной технической информацией. Т.к. часто подобные проекты заканчиваются, не успев начаться. А те, которые доходят до продакшена и реально работают и приносят пользу, не афишируются и скрываются от ИТ сообщества.
Да, во фразе опущены слова (и это не было байтом или чем-то подобным), т.к. очевидно, что считать строгую типизацию проблемой в целом — это крайняя степень профессиональной деформации. Достаточно посмотреть на языки, которые костылями прибивают себе типы через комментарии, аннотации, декораторы и тому подобное.
О каких обывателях мы говорим? Стажеры и джуны или мимо проходящие курьеры? Базовую идею типов можно за полчаса объяснить водителю такси по дороге на работу. Да и школьники на уроках информатики как-то без особых проблем понимают, что есть строки, а есть целые и дробные числа. Дженерики, юнионы и так далее тоже не рокет саенс. Не нужно курить теорию типов, что уметь этим пользоваться на базовом уровне. Хочется верить, что в индустрии не настолько все плохо...
Неужели современные начинающие разработчики так страдают и "не могут в типы"? Лично мое мнение, разработчик должен начинать со строгой типизации, а не "коверкать" себе жизнь ее отсутствием. Динамическая типизация это важная фича, но к ней можно "пускать" только окрепшие умы. Хочется верить, что любого джуна можно пересадить с JS на TS за недельку-другую. Зато какой профит для проекта, продукта, компании. А если человек упирается или не может, то нужен ли он такой в команде?
Все верно. Центр масс это не константная точка на автомобиле. Она смещается в зависимости от веса пассажиров и груза, а также их расположения в кабине и кузове. Но опять же для простоты центр масс (или тяжести) автомобиля указывается для стоящего на ровной горизонтальной поверхности нормально снаряженного автомобиля. Интересная публикация на Драйв2 про ручной расчет координат центра тяжести https://www.drive2.ru/l/522055268767367302/.
Здесь основная идея в том, что идеально правильный пробег автомобиля с точки зрения физики - это путь его центра масс в пространстве, где путь - это общая длина траектории этой точки. На счет геометрического центра соглашусь, наверное, это более корректное и оптимальное решение. Спасибо!
А максимальная накрутка по ГЛОНАСС, когда машину везут на эвакуаторе ;)
На самом деле, оба значения и пробег, и моточасы важны для учета технического обслуживания. Например, нет смысла вести регламент замены шин по моточасам у спецтехники, которая основную полезную работу делает, стоя на месте. Но на гражданских автомобилях для всех ТО используется именно пробег, потому что так проще, хотя силовой агрегат все-таки стоило бы обслуживать по моточасам.
И да, связь условная. Блок управления современного автомобиля хоть и пытается снизить погрешность в расчете реального пробега, но он не ведет учет износа расходников и агрегатов напрямую.
BMW и VAG в этом плане очень развиты, все видели их гирлянды на приборках, когда кончилась омывайка и перегорела левая фара. Но даже у них по большей части контроль выполняется на уровне "вышел из строя" / "работает в штатном режиме".
Кто владеет роботом-пылесосом, там есть раздел "расходники", где в процентах указан износ щеток, барабана и так далее. Этот износ в процентах всего лишь доля оставшегося заранее прописанного максимального пробега каждого расходника до замены. И если его вытащить и вставить обратно, нажав в приложении нужную кнопку, то мы просто сбросим оставшийся пробег до 100%.
Все верно! Напоминаю, что это лишь первая часть цикла статей. Я решил не "пихать" все в одну. Поэтому сейчас введение как первая статья кажется "ни о чем и обо всем".
Как я и писал, применение здесь очень узкое - показать пользователю, что нет идеальных способов расчета пробега ТС. В частности, извечная война: значение одометра на приборке автомобиля против рассчитанного пробега по ГНСС в программе. Клиент приходит с вполне логичным вопросом: "А чему верить?".
Это целый класс ПО - системы мониторинга транспорта (СМТ). И нет, это не очередная реклама такого сервиса, хотя я и являюсь основателем и разработчиком одной из таких ;) И нет, я не буду петь дифирамбы своей СМТ - статьи про другое.
Заголовок не соответствует содержимому: "Цифровая трансформация в логистике". Цифровой трансформации здесь нет, только интеграция программного решения и автоматизация отчетности по движению ГСМ на основе данных с навигационного терминала и датчика уровня топлива. И это не логистика, это обычный мониторинг транспорта. Логистика решает вопросы планирования и маршрутизации (будущее), мониторинг - наблюдения в реальном времени (сейчас) и работу с историческими данными (прошлое): отчеты, сводки, дашборды. Тема очень интересная, но, к сожалению, в статье все очень поверхностно.
PostgreSQL прекрасно умеет делать модификацию значений перечислений без необходимости промежуточных "махинаций", и уже довольно давно https://www.postgresql.org/docs/current/sql-altertype.html. Неужели в MySQL это не так, что-то сомневаюсь. Честно говоря, статья притянута за уши.
Первое же предложение "Часто разработчики интересуются почему не рекомендуется использовать тип поля
enumв базе данных" намекает на какую-то надуманность, т.к. за 15 лет ни разу не слышал подобной постановки вопроса о ENUM в БД.А вся статья себя по итогу оправдывает тем, что разработчики выкатили на прод в базу кривое значение в enum: "Через какое-то время была замечена грамматическая ошибка в слове "racing" и принято решение её исправить."
Так замеры не делаются. Нужно срочно все перевести на JMH (https://github.com/openjdk/jmh) с прогревом JVM и прогоном в минимум 10 раз с выведением средних результатов. Нельзя утверждать о каких-то сравнениях, не предоставив информацию о входных данных (размер входного файла, характеристики железа, сборка и версия JDK и так далее).
Ну и в дополнение к цитате Joshua Bloch, Шипилёв говорил, что знает только пару кейсов, когда можно использовать LinkedList вместо ArrayList, но даже тогда выигрыш настолько несущественный, что проще всегда использовать ArrayList ;)
А какой это open source есть у JIRA? О чем речь?
Согласен. Платить приходиться через схемы. Постоянно прилетают письма про отказ от поддержки, уход от обслуживания и так далее. А пользоваться бесплатной версией просто страшно, т.к. в любой момент могут удалить без предупреждения. И это касается всех Atlassian продуктов.
Мы в итоге развернули себе GitLab CE. После JIRA, конечно, жесть как неудобно, зато теперь не нужно платить и все риски, связанные с политикой решены. Главное, бэкапы делать постоянно на внешний сервер :)
Поддерживаю.
У нас в компании своя разработка. Написанный телематический сервер, который поддерживает тысячи разных девайсов от десятка производителетей. В рамках различных протоколов (открытых и проприетарных) поддерживается порядка 500 пунктов, которые можно получить с самого терминала, плюс переферийные датчики, входы/выходы цифровые, аналоговые, импульсные, чтение с CAN, BLE, датчики нагрузки, акселерометры и так далее. Дискретность данных порядка 5 записей в минуту (можно увеличить, если требуется). В итоге "в сухом остатке на диске" на 1 ТС, для которой выкрутили получение всего и вся, уходит максимум несколько десятков мегабайт в сутки.
У нас 25 гигов в час не получается набрать, даже если мы передаем видео с камер кругого обзора в 360 в реальном времени. Насколько надо написать неоптимально протокол и выбрать движок хранения данных, чтобы получить 600 Гигабайт в сутки с 1 ТС.
Все верно. Пример из статьи только для изучения подходит, для продакшена не годится.
Я бы сказал, если есть рекорды, то лучше вообще отказаться от ломбока.
Приложу свой пример 2х летней давности, если Автор не против. По сути ничего не изменилось. Оно и 5 лет назад делалось также :) https://github.com/binakot/Java-Spring-RabbitMQ-Example
Раньше docker-compose (через тире) был отдельной утилитой, которую как бинарник отдельно качали и делали симлинк на каталог бинарников. Сейчас docker compose (без тире), начиная с версии 2.0, входит в стандартный пакет докера и ставить отдельно его не надо. По сути все тоже самое, поменяли просто API обращения к Docker Compose в CLI.
По поводу ошибки маппинга портов, уверен на 99%, что проблема в отступах в yaml файле, в статье все съехало. Должно быть так:
Автор, спасибо за интересную статью! Особенно круто, когда гос.проекты позволяют делиться подробной технической информацией. Т.к. часто подобные проекты заканчиваются, не успев начаться. А те, которые доходят до продакшена и реально работают и приносят пользу, не афишируются и скрываются от ИТ сообщества.
Рекомендую попробовать вот эту тулзу https://github.com/timescale/timescaledb-parallel-copy. Написана на golang, от создателей одного из самых популярных расширений для PostgreSQL — TimescaleDB.
Я на нее переехал со встроенного COPY. Позволяет в несколько потоков грузить данные, мне дало прирост на порядок.
Было бы круто увидеть сравнение по производительности с тем, что рассмотрено в статье.
Да, во фразе опущены слова (и это не было байтом или чем-то подобным), т.к. очевидно, что считать строгую типизацию проблемой в целом — это крайняя степень профессиональной деформации. Достаточно посмотреть на языки, которые костылями прибивают себе типы через комментарии, аннотации, декораторы и тому подобное.
О каких обывателях мы говорим? Стажеры и джуны или мимо проходящие курьеры? Базовую идею типов можно за полчаса объяснить водителю такси по дороге на работу. Да и школьники на уроках информатики как-то без особых проблем понимают, что есть строки, а есть целые и дробные числа. Дженерики, юнионы и так далее тоже не рокет саенс. Не нужно курить теорию типов, что уметь этим пользоваться на базовом уровне. Хочется верить, что в индустрии не настолько все плохо...
Неужели современные начинающие разработчики так страдают и "не могут в типы"? Лично мое мнение, разработчик должен начинать со строгой типизации, а не "коверкать" себе жизнь ее отсутствием. Динамическая типизация это важная фича, но к ней можно "пускать" только окрепшие умы. Хочется верить, что любого джуна можно пересадить с JS на TS за недельку-другую. Зато какой профит для проекта, продукта, компании. А если человек упирается или не может, то нужен ли он такой в команде?
Проблемы Typescript: строгая типизация, дженерики, сложные типы. Вы это серьезно? Что вообще происходит в ИТ -_-