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 за недельку-другую. Зато какой профит для проекта, продукта, компании. А если человек упирается или не может, то нужен ли он такой в команде?
Первое время спасался под сплитом :) Переехал из Сибири в Краснодар 5 лет назад. Сейчас уже привык к жаре ;) К тому же адская жара стоит буквально пару недель, зато какая зима!
Уехал, кстати, не в Москву/Питер, а в Краснодар. Во время учебы в ВУЗе был тем самым сисадмином из видео на полставки (12к), после пару лет работал на удаленке в США. Местное ИТ действительно в ужасном состоянии. Есть какие-то веб-студии и все. Один одногруппник открыл свою контору, берет местные проекты там. Такого навидался :)
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: строгая типизация, дженерики, сложные типы. Вы это серьезно? Что вообще происходит в ИТ -_-
Можно пойти еще дальше. И открыть прямо из СУБД сервис с REST API http://postgrest.org/en/v7.0.0. И это далеко не все.
Да, извиняюсь.
Спасибо за дайджест! Битая ссылка на https://spring.io/blog/2020/04/17/spring-cloud-2020-0-0-m1-released
Он всегда здесь был. Ниоткуда они не "переносились" :)
Первое время спасался под сплитом :) Переехал из Сибири в Краснодар 5 лет назад. Сейчас уже привык к жаре ;) К тому же адская жара стоит буквально пару недель, зато какая зима!
Уехал, кстати, не в Москву/Питер, а в Краснодар. Во время учебы в ВУЗе был тем самым сисадмином из видео на полставки (12к), после пару лет работал на удаленке в США. Местное ИТ действительно в ужасном состоянии. Есть какие-то веб-студии и все. Один одногруппник открыл свою контору, берет местные проекты там. Такого навидался :)
Полностью поддерживаю! На Югах ИТ живет ️️