У робота есть сенсоры - какие угодно (радар, лидар, видеокамера, тактильный, магнитометр, камера ночного видения, гироскоп, акселерометр, GPS). У него есть цифровая карта местности. Впереди летят квадрокоптеры и доразведывают маршрут с точностью до сантиметра. Робот всегда может положиться на радиоуправление из базового лагеря. Роботу нипочем ураганный ветер и холод. Роботы уже ездят по городским улицам и по Марсу, делают сальто. Так что я не вижу никаких непреодолимых препятствий к тому, чтобы роботы могли проходить те же горные маршруты, что и альпинисты. Единственное исключение - когда большие размеры робота не позволяют ему протиснуться через какую-то узость, но это больше относится к пещерам ("шкуродеры"), чем к горным вершинам. И такой участок можно и обойти.
Я думаю на этим. Но задача почти неразрешимая из-за низкой плотности воздуха и ураганных ветров. Вертолет высоко не поднимается, коптер способен поднять на большую высоту (и спустить вниз) пару килограммов максимум, аэростат сносит ураганным ветром. Есть одна идея, но маловероятно, что она реализуема.
Государство прямо разорилось! 12 спасателей на "точку притяжения" всей страны. Да налоги на бизнес, который крутится вокруг Эльбруса, в тысячи раз больше! Или, может быть, окружить Эльбрус кордонами, чтобы вообще не тратиться? Правда, на охранников больше денег уйдет.
Уж лучше бордюры и тротуары каждый год перекладывать, чем людей спасать. А вот Вы как влияете на то, куда идут налоги с Вас? Все остальные расходы Вас устраивают?
И сколько Вы уже заплатили? Вы правительству Непала платили или Китая (Эверест как раз там)? Судя по тому, что на спасательные мероприятия денег почти нет, и альпинистов оставляют умирать, Вы заплатили очень немного. И кто тонет, тот пусть предварительно оплатит работу спасателей на год вперед (спасение утопающих ... сами знаете). А уж автолюбителям, попавшим в ДТП, точно не нужно предоставлять услуги государственной медицины - пусть покупают частную медстраховку или продают квартиру.
Вы очень хорошо знаете, что именно другие должны делать или не делать и как они должны жить и энергично трудиться исключительно для пользы общества и решения мировых проблем. А сами ведете образ жизни, приятный всем окружающим, и ничего после себя не оставляете. А люди, которым нравятся горы, - ну пусть себе умирают, так как не вписываются в Вашу картину мира и сами виноваты в своих увлечениях. И вообще, меньше людей - меньше мусора.
Кодируйте UUIDv7 в выгузках в компактный текстовый формат. А вообще сравнивать идентификаторы глазами - это плохая идея. Пользователи вообще не должны видеть идентификаторы, ведь им нужны бизнес-данные. А для внешних потребителей нужно использовать стандартизованные классификаторы и преобразовывать суррогатные ключи в натуральные, действительные в отчетную дату.
Надо сказать, что ИИ в основном агрегируют те меры, которые уже предлагаются или описываются в интернете. Но хотелось бы видеть более творческий подход, основанный на глубоком анализе, а также на исследовании эффективности и побочных эффектов сложившейся практики в разных странах.
Например, формально поддерживаемый законодательством бессрочный наём фактически не работает. Заемный труд и принуждение к увольнению широко распространены. Нужно не закрывать на это глаза, а искать продуманные альтернативные решения, отвечающие интересам и работников/соискателей, и бизнеса. Трудовые отношения нужно вернуть в правовое поле и адаптировать к современным вызовам (удаленная работа, проектная работа, ротация и "горизонтальный рост", искусственный интеллект, гибкие организационные структуры и т.д.).
Это не "наём сломан" (правильное написание - наём), а классический образец market failure (фиаско рынка). Не поможет ни новая частная платформа найма, ни призывы к участникам рынка труда. Ничто не поможет, кроме эффективного государственного регулирования рынка труда. После Великой депрессии государственное регулирование («Новый курс» Франклина Рузвельта) прекрасно зарекомендовало себя на финансовых рынках всего мира. Свобода работодателей и посредников должна быть разумным образом ограничена. Я не имею в виду бюрократические фантазии и прямое государственное вмешательство. Серьезная проблема требует серьезного и беспристрастного научного подхода. Трудовой кодекс несостоятелен, так как слабо связан с реальностью. Но не заметно, что российское государство и олигархи замечают проблему. Пока у них всё вроде хорошо. Проблема должна дозреть до состояния катастрофы, чтобы ею занялись.
Производитель памяти Micron Technology пытается подстегнуть спрос на память. Это просто маркетинговый ход. Если внимательно прочитать, что имеется в виду под Level 4 по классификации SAE, то вырисовывается совершенно противоположная картина. Такой автономный автомобиль способен выполнять все задачи по вождению самостоятельно и без вмешательства человека, но только в определенных условиях (географических, погодных или в конкретных сценариях). Это фактически будет означать, что реальная автономность потребуется лишь на физически изолированных от обычного транспорта и пешеходов специальных выделенных полосах движения или дорогах. В таких "тепличных" условиях, где значительная нагрузка по регулированию движения будет переложена на инфраструктуру ("умную дорогу"), не понадобятся суперумные транспортые средства с запредельными объемами памяти.
Вы хотите, чтобы в одном человеке сочетались несочетаемые и даже взаимоисключающие вещи. В результате получите недоспециалиста во всех областях с хорошо подвешенным языком («и швец, и жнец, и на дуде игрец»).
Судя по тексту вакансии Вам нужны три разных человека:
Backend Engineer (Python разработчик инфраструктуры и API для интеграции моделей)
Machine Learning Engineer (специалист по RAG, агентам и пайплайнам на базе LLM)
Applied Scientist (исследователь, улучшающий качество моделей и архитектуры)
Я не поленился сходить на сайт https://gptunnel.ru/, заблудился там, и вижу, что остро необходим еще и Product Designer.
А если вам еще нужен и лидер (хотя мне кажется, что он уже есть), то ищите еще и Project Manager.
Понятно, что бюджет ограничен. Кого-то можно взять на ограниченный срок, не сразу или по совместительству. А может быть он у вас уже и есть, просто хотелось сразу всего и побольше от нового кандидата.
Вот это хотелки у работодателя! От души посмеялся! Интересно, чем заняты остальные 30-50 сотрудников помимо креативной рекламы, если столько хотят взвалить на одного человека? И кто клюнет на такую вакансию? Должно быть, такой же великий комбинатор. Чувство меры иногда полезно.
В свете того, что Китай собирается удорожать доступ к своим LLM, бизнес-идея агрегатора с оплатой по мере использования может действительно взлететь. Пожелаю ему удачи!
Таблица курсов валют. Дата, Валюта, Курс.Объясните здесь смысл поля id?
Валюта российский рубль имела обозначение RUR, а с 1998 года стала RUB. И это не единственный такой пример. Не существует в природе гарантированно неизменных и уникальных натуральных ключей. Например, известны дубликаты ИНН, MAC-адресов. А ключ для связи таблиц (поле id) изменяться не должен.
Каждая таблица ОБЯЗАНА иметь created_at и updated_at Не обязана. Должна быть целесообразность. Не надо категорических суждений.
Та же таблица курсов валют. Ее можно хоть всю передавать, хоть загрузить из интернетов.
В этом случае будет только актуальная таблица. А если в целях аудита понадобится посмотреть или вставить в расчеты ошибочные исторические данные?
Я бы посоветовал: используйте uuid7 для id, если база не требует экстремальной производительности.
Я уже устал опровергать взятый с потолка миф, что UUIDv7 якобы снижает производительность по сравнению с целочисленными ID.
С внешними ключами это еще та морока, не забыть словить какой нибудь каскадный update или delete.
Никаких update или delete с ключами происходить не должно. Ключи должны быть вечными и неизменными. Значения атрибутов и связей могут изменяться с течением времени - для этого есть поля valid_from и valid_to (или их синонимы start_date и end_date).
Внешних ключей (и других ограничений) не должно быть только у таблиц, куда загружаются сырые данные, чтобы загрузка происходила без помех. Потом эти данные всё равно нужно валидировать, прежде чем использовать.
Миграция - слишком громкое слово. Достаточно только заменить прежнюю функцию генерации UUID на uuidv7(). Это возможно всегда, быстро и без побочных эффектов. Ни столбец с типом данных UUID, ни прежние UUID трогать не надо. В одном столбце с типом данных UUID мирно уживаются UUID разных версий. По мере роста количества свежих UUIDv7 скорость работы БД будет увеличиваться.
В-третьих, работает - не трогай.
Значит, еще не припекло. Когда БД начнет с трудом ворочаться, тронете.
Джойны по UUIDv7 и по числовым ID работают одинаково быстро. Сравнение происходит уже по небольшому количеству старших битов UUIDv7, а не по всем 128 битам.
Числовые ID занимают меньше места только на первый взгляд. Ведь при слиянии данных из нескольких таблиц (систем-источников) приходится дублировать данные - теперь уже с новыми уникальными ключами, так как числовые ID совершенно разных записей из разных источников часто совпадают.
В целом статья мне понравилась, но ее нужно "полировать".
-- Распределённая система / микросервисы:
id UUID PRIMARY KEY
DEFAULT gen_random_uuid() -- v4
-- Или генерируйте UUIDv7 на стороне приложения
После появления встроенной функции uuidv7() в PostgreSQL не осталось ни одного разумного аргумента в пользу UUIDv4. Заранее отвечаю тем, кто боится раскрыть дату и время генерации UUIDv7, - функция uuidv7() позволяет исказить эту дату путем смещения значения таймстемпа даже не на дни, а на тысячелетия, причем очень удобным и безопасным способом.
Совершенно непонятно, зачем в случае микросервисов нужно генерировать UUIDv7 на стороне приложения, если есть такая замечательная встроенная функция uuidv7() в PostgreSQL, формирующая таймстемп с точностью 250 наносекунд.
В случае распределенной системы удобно иметь два ключа в записи: один генерится на клиенте (для сверки), а второй на сервере (для лучшей монотонности ключей, первичный ключ) - функцией uuidv7(). Об этом упоминается в RFC 9562:
Applications using a monolithic database may find using database-generated UUIDs (as opposed to client-generated UUIDs) provides the best UUID monotonicity. In addition to UUIDs, additional identifiers MAY be used to ensure integrity and feedback.
Проблема в клиентуре: соискатели не станут тратить еще много часов в сутки на второй сервис, а работодатели тоже не захотят платить второму сервису. Вся клиентура стекается на один сервис. Там соискатели имеют самый широкий выбор работодателей, а работодатели - самый широкий выбор соискателей. Поэтому значимый второй сервис не возникнет, даже если его можно сделать за копейки.
Трудоустройство должно быть организованным рынком, как, например, финансы, где практически все торги внутри страны сосредоточены на одной национальной фондовой бирже. Национальная фондовая биржа - это не бюрократический государственный сервис, но и не частная монополия (в отличие от HH). Ее строго контролируют с одной стороны брокеры (они ее акционеры), а с другой - центральный банк или другой государственный финансовый регулятор. Но к такому строгому, но не забюрократизированному регулированию финансов государства пришли не сразу, а через череду ужасных финансовых кризисов.
В России государство просто закрывает глаза на безобразия дикого рынка труда в IT, ведь техноолигархов всё устраивает - у них тысячи соискателей на одну вакансию. Да и IT отрасль сложная - кто из госчиновников понимает, как ее регулировать?
У робота есть сенсоры - какие угодно (радар, лидар, видеокамера, тактильный, магнитометр, камера ночного видения, гироскоп, акселерометр, GPS). У него есть цифровая карта местности. Впереди летят квадрокоптеры и доразведывают маршрут с точностью до сантиметра. Робот всегда может положиться на радиоуправление из базового лагеря. Роботу нипочем ураганный ветер и холод. Роботы уже ездят по городским улицам и по Марсу, делают сальто. Так что я не вижу никаких непреодолимых препятствий к тому, чтобы роботы могли проходить те же горные маршруты, что и альпинисты. Единственное исключение - когда большие размеры робота не позволяют ему протиснуться через какую-то узость, но это больше относится к пещерам ("шкуродеры"), чем к горным вершинам. И такой участок можно и обойти.
Я думаю на этим. Но задача почти неразрешимая из-за низкой плотности воздуха и ураганных ветров. Вертолет высоко не поднимается, коптер способен поднять на большую высоту (и спустить вниз) пару килограммов максимум, аэростат сносит ураганным ветром. Есть одна идея, но маловероятно, что она реализуема.
Знаете, сколько стоит лицензия на восхождение на Эверест?
В стоимость стандартного пакета «всё включено» входят:
Официальный пермит (разрешение) Непала - 15 000 $ (около 1 150 000 рублей)
Экологический сбор (мусорный депозит) - 4 000 $ (около 310 000 рублей)
А потом этих людей за такие деньги оставляют умирать на горе.
Я в принципе не против обязательного страхования, но дьявол как всегда в деталях.
Горным туризмом, много лет, до 3 к.с. включительно. А если не переходить на личности, то что Вас смущает в концепции?
Государство прямо разорилось! 12 спасателей на "точку притяжения" всей страны. Да налоги на бизнес, который крутится вокруг Эльбруса, в тысячи раз больше! Или, может быть, окружить Эльбрус кордонами, чтобы вообще не тратиться? Правда, на охранников больше денег уйдет.
Уж лучше бордюры и тротуары каждый год перекладывать, чем людей спасать. А вот Вы как влияете на то, куда идут налоги с Вас? Все остальные расходы Вас устраивают?
И сколько Вы уже заплатили? Вы правительству Непала платили или Китая (Эверест как раз там)? Судя по тому, что на спасательные мероприятия денег почти нет, и альпинистов оставляют умирать, Вы заплатили очень немного. И кто тонет, тот пусть предварительно оплатит работу спасателей на год вперед (спасение утопающих ... сами знаете). А уж автолюбителям, попавшим в ДТП, точно не нужно предоставлять услуги государственной медицины - пусть покупают частную медстраховку или продают квартиру.
Вы очень хорошо знаете, что именно другие должны делать или не делать и как они должны жить и энергично трудиться исключительно для пользы общества и решения мировых проблем. А сами ведете образ жизни, приятный всем окружающим, и ничего после себя не оставляете. А люди, которым нравятся горы, - ну пусть себе умирают, так как не вписываются в Вашу картину мира и сами виноваты в своих увлечениях. И вообще, меньше людей - меньше мусора.
Кодируйте UUIDv7 в выгузках в компактный текстовый формат. А вообще сравнивать идентификаторы глазами - это плохая идея. Пользователи вообще не должны видеть идентификаторы, ведь им нужны бизнес-данные. А для внешних потребителей нужно использовать стандартизованные классификаторы и преобразовывать суррогатные ключи в натуральные, действительные в отчетную дату.
А можно ли сделать так, чтобы LLM-ка сама последовательно задавала все необходимые уточняющие вопросы промпта с учетом того, что ей уже известно?
А вот какие решения проблемы предложил искусственный интеллект DeepSeek: https://chat.deepseek.com/share/ptfw1ihgzjp9iorbpw
Я с большим интересом это прочитал. Надо сказать, что ответ DeepSeek превзошел мои ожидания. Это вовсе не AI slop, а весьма продуманная система мер.
А вот, что предложил Perplexity без использования мощных платных моделей (LLM): https://www.perplexity.ai/search/2136f90b-8760-44d0-afd2-b01d94fe478e
Не так блестяще, но тоже интересно.
Надо сказать, что ИИ в основном агрегируют те меры, которые уже предлагаются или описываются в интернете. Но хотелось бы видеть более творческий подход, основанный на глубоком анализе, а также на исследовании эффективности и побочных эффектов сложившейся практики в разных странах.
Например, формально поддерживаемый законодательством бессрочный наём фактически не работает. Заемный труд и принуждение к увольнению широко распространены. Нужно не закрывать на это глаза, а искать продуманные альтернативные решения, отвечающие интересам и работников/соискателей, и бизнеса. Трудовые отношения нужно вернуть в правовое поле и адаптировать к современным вызовам (удаленная работа, проектная работа, ротация и "горизонтальный рост", искусственный интеллект, гибкие организационные структуры и т.д.).
Это не "наём сломан" (правильное написание - наём), а классический образец market failure (фиаско рынка). Не поможет ни новая частная платформа найма, ни призывы к участникам рынка труда. Ничто не поможет, кроме эффективного государственного регулирования рынка труда. После Великой депрессии государственное регулирование («Новый курс» Франклина Рузвельта) прекрасно зарекомендовало себя на финансовых рынках всего мира. Свобода работодателей и посредников должна быть разумным образом ограничена. Я не имею в виду бюрократические фантазии и прямое государственное вмешательство. Серьезная проблема требует серьезного и беспристрастного научного подхода. Трудовой кодекс несостоятелен, так как слабо связан с реальностью. Но не заметно, что российское государство и олигархи замечают проблему. Пока у них всё вроде хорошо. Проблема должна дозреть до состояния катастрофы, чтобы ею занялись.
Производитель памяти Micron Technology пытается подстегнуть спрос на память. Это просто маркетинговый ход. Если внимательно прочитать, что имеется в виду под Level 4 по классификации SAE, то вырисовывается совершенно противоположная картина. Такой автономный автомобиль способен выполнять все задачи по вождению самостоятельно и без вмешательства человека, но только в определенных условиях (географических, погодных или в конкретных сценариях). Это фактически будет означать, что реальная автономность потребуется лишь на физически изолированных от обычного транспорта и пешеходов специальных выделенных полосах движения или дорогах. В таких "тепличных" условиях, где значительная нагрузка по регулированию движения будет переложена на инфраструктуру ("умную дорогу"), не понадобятся суперумные транспортые средства с запредельными объемами памяти.
Вы хотите, чтобы в одном человеке сочетались несочетаемые и даже взаимоисключающие вещи. В результате получите недоспециалиста во всех областях с хорошо подвешенным языком («и швец, и жнец, и на дуде игрец»).
Судя по тексту вакансии Вам нужны три разных человека:
Backend Engineer (Python разработчик инфраструктуры и API для интеграции моделей)
Machine Learning Engineer (специалист по RAG, агентам и пайплайнам на базе LLM)
Applied Scientist (исследователь, улучшающий качество моделей и архитектуры)
Я не поленился сходить на сайт https://gptunnel.ru/, заблудился там, и вижу, что остро необходим еще и Product Designer.
А если вам еще нужен и лидер (хотя мне кажется, что он уже есть), то ищите еще и Project Manager.
Понятно, что бюджет ограничен. Кого-то можно взять на ограниченный срок, не сразу или по совместительству. А может быть он у вас уже и есть, просто хотелось сразу всего и побольше от нового кандидата.
Вот это хотелки у работодателя! От души посмеялся! Интересно, чем заняты остальные 30-50 сотрудников помимо креативной рекламы, если столько хотят взвалить на одного человека? И кто клюнет на такую вакансию? Должно быть, такой же великий комбинатор. Чувство меры иногда полезно.
В свете того, что Китай собирается удорожать доступ к своим LLM, бизнес-идея агрегатора с оплатой по мере использования может действительно взлететь. Пожелаю ему удачи!
Это неудачное правило. Тот, кто присылает данные, может изменить свой классификатор, и что тогда делать?
Валюта российский рубль имела обозначение RUR, а с 1998 года стала RUB. И это не единственный такой пример. Не существует в природе гарантированно неизменных и уникальных натуральных ключей. Например, известны дубликаты ИНН, MAC-адресов. А ключ для связи таблиц (поле id) изменяться не должен.
В этом случае будет только актуальная таблица. А если в целях аудита понадобится посмотреть или вставить в расчеты ошибочные исторические данные?
Я уже устал опровергать взятый с потолка миф, что UUIDv7 якобы снижает производительность по сравнению с целочисленными ID.
Никаких update или delete с ключами происходить не должно. Ключи должны быть вечными и неизменными. Значения атрибутов и связей могут изменяться с течением времени - для этого есть поля valid_from и valid_to (или их синонимы start_date и end_date).
Внешних ключей (и других ограничений) не должно быть только у таблиц, куда загружаются сырые данные, чтобы загрузка происходила без помех. Потом эти данные всё равно нужно валидировать, прежде чем использовать.
Для старых версий PostgreSQL рекомендую расширение pg_uuidv7.
Миграция - слишком громкое слово. Достаточно только заменить прежнюю функцию генерации UUID на uuidv7(). Это возможно всегда, быстро и без побочных эффектов. Ни столбец с типом данных UUID, ни прежние UUID трогать не надо. В одном столбце с типом данных UUID мирно уживаются UUID разных версий. По мере роста количества свежих UUIDv7 скорость работы БД будет увеличиваться.
Значит, еще не припекло. Когда БД начнет с трудом ворочаться, тронете.
Это не так.
Джойны по UUIDv7 и по числовым ID работают одинаково быстро. Сравнение происходит уже по небольшому количеству старших битов UUIDv7, а не по всем 128 битам.
Числовые ID занимают меньше места только на первый взгляд. Ведь при слиянии данных из нескольких таблиц (систем-источников) приходится дублировать данные - теперь уже с новыми уникальными ключами, так как числовые ID совершенно разных записей из разных источников часто совпадают.
В целом статья мне понравилась, но ее нужно "полировать".
После появления встроенной функции uuidv7() в PostgreSQL не осталось ни одного разумного аргумента в пользу UUIDv4. Заранее отвечаю тем, кто боится раскрыть дату и время генерации UUIDv7, - функция uuidv7() позволяет исказить эту дату путем смещения значения таймстемпа даже не на дни, а на тысячелетия, причем очень удобным и безопасным способом.
Совершенно непонятно, зачем в случае микросервисов нужно генерировать UUIDv7 на стороне приложения, если есть такая замечательная встроенная функция uuidv7() в PostgreSQL, формирующая таймстемп с точностью 250 наносекунд.
В случае распределенной системы удобно иметь два ключа в записи: один генерится на клиенте (для сверки), а второй на сервере (для лучшей монотонности ключей, первичный ключ) - функцией uuidv7(). Об этом упоминается в RFC 9562:
Проблема в клиентуре: соискатели не станут тратить еще много часов в сутки на второй сервис, а работодатели тоже не захотят платить второму сервису. Вся клиентура стекается на один сервис. Там соискатели имеют самый широкий выбор работодателей, а работодатели - самый широкий выбор соискателей. Поэтому значимый второй сервис не возникнет, даже если его можно сделать за копейки.
Трудоустройство должно быть организованным рынком, как, например, финансы, где практически все торги внутри страны сосредоточены на одной национальной фондовой бирже. Национальная фондовая биржа - это не бюрократический государственный сервис, но и не частная монополия (в отличие от HH). Ее строго контролируют с одной стороны брокеры (они ее акционеры), а с другой - центральный банк или другой государственный финансовый регулятор. Но к такому строгому, но не забюрократизированному регулированию финансов государства пришли не сразу, а через череду ужасных финансовых кризисов.
В России государство просто закрывает глаза на безобразия дикого рынка труда в IT, ведь техноолигархов всё устраивает - у них тысячи соискателей на одну вакансию. Да и IT отрасль сложная - кто из госчиновников понимает, как ее регулировать?