странное даже здесь. Как раз профессиональную литературу перевести проще, там язык сухой. Хотя думаю как минимум в IT профессионалы все же потребляют профессиональную литературу на английском.
А вот с художественной все совсем по-другому. Перевод там это часто отдельное художественное произведение. И автоматический перевод, какой бы хороший он ни был, не заменит авторского перевода. Все же я художественную литературу читаю для удовольствия, а не чтобы смысл понять.
Я сам из айти и хоть со здоровьем у меня все более менее, шутка вполне себе в тему. Как я сам, так и многие в моем окружении очень хорошо подпадают в образ 'я лучше проеду еще две остановки, чем попрошу водителя остановиться на следующей'. Тоже преувеличение, конечно. Но тем не менее, в IT полно очень хороших специалистов с очень низкими социальными и 'общежизненными' навыками. И живем мы хорошо просто потому что так уж получилось, что есть такая высокооплачиваемая сфера, где эти навыки не то чтобы критически необходимы.
В общем по мне хорошая шутка и обижаться на стереотип здесь уж точно я бы не стал.
Мне кажется, что те, кто называет других людей 'случайными', часто сами не очень в теме. Потому что если вы действительно совсем 'неслучайный', 'илита', то вы смогли пробиться в топовый компании/направления. И там случайных людей и так, обычно, нет. Да и снобизма там часто тоже нет. А вот если вы сами эникейщик и хотите выделиться, вот тогда и получаются такие вот навешивания ярлыков.
По теме, в индустрии разработки сейчас действительно идут тектонические процессы. И некоторые конторы буквально трясет, то и дело появляются статьи о том, как целые компании переходят полностью на вайбкодинг, чуть ли не мотивацией сверху. Но в реальности (пока) поменялось довольно мало. Не то чтобы скорость набора кода была у разработчиков ограничивающим фактором. Необходимость инженеров осталась прежней. Да, надо приспосабливаться. Но мы еще очень далеко от состояния, которое описывают некоторые из комментаторов. Никто адекватный из разработчиков промт-инженеров не делает. Никто адекватный не перестает нанимать джунов, хоть ai и сгенерит код лучше них. Потому что в конце концов системы все еще нужно строить и поддерживать и отвечать за их качество. Ну а кто это не понимают, получат то, что раньше получали компании, отдававшие на дешевый отсорс все свои системы - необходимость платить дважды уже тем, кто в этом потом будет разбираться.
Так что сейчас важно не терять голову (и работу) и пытаться разделить AI как инструмент, от строительство сервисов как работы.
У них был выбор, интегрировать 10 редакторов с их внутренней экосистемой или разрабатывать один ide, который подойдёт 95% инженеров
У них же все свое - vcs, сборка. Даже из собственный golang внутри это не то, что снаружи. Там все заточено на стандартизацию. Жава/плюсы/Гошка - все живёт по одним правилам.
Поэтому единый ide да ещё с интерфейсом vscode - вполне логичное решение.
И да, другие ide не запрещены и если ты готов его настраивать - твое право. Vim/emacs туториалы там были
И если для вас важен супер низкий латенси, вам не нужен S3, посмотрите на хранилища выше по "пирамиде памяти".
я бы сказал, что это утверждение спорное, но чтобы спорить нужно все-таки иметь какую-то точку отсчета. Например, для для (распределенных) файловых систем ожидаются латенси ниже 1мс (сотни миросекунд у лидеров на рынке). Для S3 требования к латенси чуть более расслабленные. Средний пользователь aws s3 не ожидает латенси даже в десятки мс. Но это ровно до тех пор, пока ему интересен просто S3. Если мы начинаем подходить к действительно высоким нагрузкам, то ситуация резко меняется. Разница между 5ms на мегабайт против 50ms плоха даже не сама по себе - у клиентов S3 обычно батчевая нагрузка, которая закидывается бОльшей параллельностью. Но в какой-то момент повышать параллельность становится проблематичным: больше коннектов требуют больше ресурсов - если у вас клиент на питонячем boto3, то большое количество коннектов начнет заедать слишком много ресурсов и вы не сможете прокачать свою ноду/GPU целиком.
Да, тут можно много говорить о том, что в таких случаях нужно кэшировать на клиенте и будете правы в каком-то смысле. Но если вы продаете не только S3, но еще и компьют рядом, вам будет очень не сруки, если клиенты не смогут прокачать продаваемые им 400Г ноды.
Соответственно, масштабирование довольно легко происходит добавлением узлов.
Легко ровно до того момента, пока не надо считать влияние x2 нод на маржинальность. Опять же, это сильно зависит от объема трафика. Если речь про условный терабит/сек, то проблемы нет. Если же продавать быстрый тир на ssd, то каждая точка, через которую проходит трафик, добавляет буквально количество нод равное количеству стораджовых нод. В вашей архитектуре таких точек получается как минимум две. То есть на каждую стораджовую ноду с флеш-дисками, вам придется закладывать одну DPL ноду и одну проксю. В идеале промежуточных точек между клиентом и диском должно быть ровно ноль, но это уже разговор про что-нибудь вроде rdma или client-side 'proxy'
Кейс 2: Data Lakehouse и горячее хранилище на 1 ПБ
для столь небольшого объема данных при довольно высокой нагрузке мы решили использовать NVMe-накопители, а в качестве алгоритма защиты данных — трехкратную репликацию (RFx3). Тесты профиля нагрузки заказчика показали, что Erasure Coding в данном случае не подходит. Причина — более медленные операции записи и чтения файлов
Интересно, о каком порядке латенси здесь идет речь? 200К рпс на 200 гигабит это работа объектами в сотни килобайт. На таких профилях нагрузки в случае ssd не удивлюсь, если львиная доля латенси идет даже не со стораджа, а с вашей мета базы.
Уровень 3 — Proxy Layer
Не становится узким местом у вас? Прокачивать весь траф через L7 (похоже, судя по слову 'кэширование') проксю? DSR не используете для отдачи трафа с меньшим количеством хопов?
Вообще в целом интересно было бы послушать, как у вас происходит эволюция требований в мире нагрузки для ML/AI. Трафик в сотни гигабит уже очень мало. Снимать с петабайта nvme дисков (особенно с mirror-3) можно уже 1-2 терабита, а то и больше.
Разводятся именно ради алиментов и дальнейшего отжима бабла и имущества.
У вас показания не сходятся.
Вы выше пишете, что сейчас принимают законы, чтобы можно было больше получать при разводе. И тут же пишете, что цель развода отдать имущество. А эта цель когда появилась?
Я уверен, в большинстве разводов за последние лет 30 алименты были либо нищенские, либо вообще не платились
А то что вы приводите - это какие-то маргинальные случаи из мира обеспеченных
Странно, но что же тогда ее тянет в ЗАГС оформлять брак и пресловутое "когда поженимся
Люди меняются и узнаются. В ЗАГС люди идут на пике своих отношений. Потом многое меняется и если люди к этому не могут адаптироваться, то получается что получается.
Считать, что это как-то женщина больше тут виновата, это как минимум глупо.
Я знаю, что в самом кодинге остаётся какое-то количество "белых пятен", в которых человеческие программисты выигрывают у ИИшки по соотношению "цена-качество". Но лично для меня это edge кейсы, которые в ближайшее время исчезнут. Я просто вместе со всеми наблюдал эволюцию качества ИИ текстов и картинок. И продолжаю наблюдать эволюцию ИИ видео и кода
Между сгенеренным изображением и кодом есть одна большая разница: изображение генерится один раз и больше не трогается. Код же надо поддерживать, годами и десятилетиями.
И пока мы не наблюдаем взрыва новых сервисов, приложений, опенсорс библиотек. Хотя казалось бы, увеличение производительности разработчиков даже в 2 должны были привести к кратному росту всего, что они делают.
Что же мы видим в реальности? Много прототипов и 'я сделал игру за выходные', Но потом они уходят в небытие. Как будто написание кода не было ботлнеком.
Будем наблюдать. В качестве прототипирования и написания одноразового или неважного кода AI он действительно рулит и бибикает
Как по мне отличная тенденция. Мы уверенно движемся к тому, что учиться будут только те, кто действительно этого хочет. Все остальные будут читерить, потому что это становится максимально просто.
Го, как любой рантайм с гц, имеет проблемы с поддержкой низких латенси на одном хорошем уровне. Если вы ждёте 50мс ответа от базы, можно писать на чем угодно. А вот если захотите видеть сотни микросек, то го может начать быть проблемой
Меняем в конфиге приложения префикс таблиц (Table Prefix)
Если бы ещё ydb sdk имели такую унифицированную опцию. В реальности даже в рамках одного гошного sdk эта настройка существует только для некоторых способов взаимодействия.
Я уже не говорю о том, что это именно table префикс. Используете топики (которые не бэкапятся, кстати) или более низкоуровневое API - вам не повезло, сами добавляйте префикс к названиям сущностей.
Было бы круто, если бы этот префикс стал глобальной настройкой sdk и полностью прозрачной для клиентского кода.
странное даже здесь. Как раз профессиональную литературу перевести проще, там язык сухой. Хотя думаю как минимум в IT профессионалы все же потребляют профессиональную литературу на английском.
А вот с художественной все совсем по-другому. Перевод там это часто отдельное художественное произведение. И автоматический перевод, какой бы хороший он ни был, не заменит авторского перевода. Все же я художественную литературу читаю для удовольствия, а не чтобы смысл понять.
А говорит ли вам что-то слово 'гипербола'
Я сам из айти и хоть со здоровьем у меня все более менее, шутка вполне себе в тему. Как я сам, так и многие в моем окружении очень хорошо подпадают в образ 'я лучше проеду еще две остановки, чем попрошу водителя остановиться на следующей'. Тоже преувеличение, конечно. Но тем не менее, в IT полно очень хороших специалистов с очень низкими социальными и 'общежизненными' навыками. И живем мы хорошо просто потому что так уж получилось, что есть такая высокооплачиваемая сфера, где эти навыки не то чтобы критически необходимы.
В общем по мне хорошая шутка и обижаться на стереотип здесь уж точно я бы не стал.
Мне кажется, что те, кто называет других людей 'случайными', часто сами не очень в теме. Потому что если вы действительно совсем 'неслучайный', 'илита', то вы смогли пробиться в топовый компании/направления. И там случайных людей и так, обычно, нет. Да и снобизма там часто тоже нет. А вот если вы сами эникейщик и хотите выделиться, вот тогда и получаются такие вот навешивания ярлыков.
По теме, в индустрии разработки сейчас действительно идут тектонические процессы. И некоторые конторы буквально трясет, то и дело появляются статьи о том, как целые компании переходят полностью на вайбкодинг, чуть ли не мотивацией сверху. Но в реальности (пока) поменялось довольно мало. Не то чтобы скорость набора кода была у разработчиков ограничивающим фактором. Необходимость инженеров осталась прежней. Да, надо приспосабливаться. Но мы еще очень далеко от состояния, которое описывают некоторые из комментаторов. Никто адекватный из разработчиков промт-инженеров не делает. Никто адекватный не перестает нанимать джунов, хоть ai и сгенерит код лучше них. Потому что в конце концов системы все еще нужно строить и поддерживать и отвечать за их качество. Ну а кто это не понимают, получат то, что раньше получали компании, отдававшие на дешевый отсорс все свои системы - необходимость платить дважды уже тем, кто в этом потом будет разбираться.
Так что сейчас важно не терять голову (и работу) и пытаться разделить AI как инструмент, от строительство сервисов как работы.
У них был выбор, интегрировать 10 редакторов с их внутренней экосистемой или разрабатывать один ide, который подойдёт 95% инженеров
У них же все свое - vcs, сборка. Даже из собственный golang внутри это не то, что снаружи. Там все заточено на стандартизацию. Жава/плюсы/Гошка - все живёт по одним правилам.
Поэтому единый ide да ещё с интерфейсом vscode - вполне логичное решение.
И да, другие ide не запрещены и если ты готов его настраивать - твое право. Vim/emacs туториалы там были
А у кого 'у нас' простите? В технологических компаниях и собеседуют специалисты, а принимают решения непосредственные руководители.
Не знаю про какой мир пишет автор, но к счастью я живу не в нем.
я бы сказал, что это утверждение спорное, но чтобы спорить нужно все-таки иметь какую-то точку отсчета. Например, для для (распределенных) файловых систем ожидаются латенси ниже 1мс (сотни миросекунд у лидеров на рынке). Для S3 требования к латенси чуть более расслабленные. Средний пользователь aws s3 не ожидает латенси даже в десятки мс. Но это ровно до тех пор, пока ему интересен просто S3. Если мы начинаем подходить к действительно высоким нагрузкам, то ситуация резко меняется. Разница между 5ms на мегабайт против 50ms плоха даже не сама по себе - у клиентов S3 обычно батчевая нагрузка, которая закидывается бОльшей параллельностью. Но в какой-то момент повышать параллельность становится проблематичным: больше коннектов требуют больше ресурсов - если у вас клиент на питонячем boto3, то большое количество коннектов начнет заедать слишком много ресурсов и вы не сможете прокачать свою ноду/GPU целиком.
Да, тут можно много говорить о том, что в таких случаях нужно кэшировать на клиенте и будете правы в каком-то смысле. Но если вы продаете не только S3, но еще и компьют рядом, вам будет очень не сруки, если клиенты не смогут прокачать продаваемые им 400Г ноды.
Легко ровно до того момента, пока не надо считать влияние x2 нод на маржинальность. Опять же, это сильно зависит от объема трафика. Если речь про условный терабит/сек, то проблемы нет. Если же продавать быстрый тир на ssd, то каждая точка, через которую проходит трафик, добавляет буквально количество нод равное количеству стораджовых нод. В вашей архитектуре таких точек получается как минимум две. То есть на каждую стораджовую ноду с флеш-дисками, вам придется закладывать одну DPL ноду и одну проксю. В идеале промежуточных точек между клиентом и диском должно быть ровно ноль, но это уже разговор про что-нибудь вроде rdma или client-side 'proxy'
Интересно, о каком порядке латенси здесь идет речь? 200К рпс на 200 гигабит это работа объектами в сотни килобайт. На таких профилях нагрузки в случае ssd не удивлюсь, если львиная доля латенси идет даже не со стораджа, а с вашей мета базы.
Не становится узким местом у вас? Прокачивать весь траф через L7 (похоже, судя по слову 'кэширование') проксю? DSR не используете для отдачи трафа с меньшим количеством хопов?
Вообще в целом интересно было бы послушать, как у вас происходит эволюция требований в мире нагрузки для ML/AI. Трафик в сотни гигабит уже очень мало. Снимать с петабайта nvme дисков (особенно с mirror-3) можно уже 1-2 терабита, а то и больше.
Скажем так, судя по вашим ответам в этом посте, они могут быть правы.
Из принципа платить минимум семье, которая содержит вашего сына и гордиться и писать на Хабре об этом - такого я ещё не видел
У вас показания не сходятся.
Вы выше пишете, что сейчас принимают законы, чтобы можно было больше получать при разводе. И тут же пишете, что цель развода отдать имущество. А эта цель когда появилась?
Я уверен, в большинстве разводов за последние лет 30 алименты были либо нищенские, либо вообще не платились
А то что вы приводите - это какие-то маргинальные случаи из мира обеспеченных
Люди меняются и узнаются. В ЗАГС люди идут на пике своих отношений. Потом многое меняется и если люди к этому не могут адаптироваться, то получается что получается.
Считать, что это как-то женщина больше тут виновата, это как минимум глупо.
Я - страшный мужчина :/
Между сгенеренным изображением и кодом есть одна большая разница: изображение генерится один раз и больше не трогается. Код же надо поддерживать, годами и десятилетиями.
И пока мы не наблюдаем взрыва новых сервисов, приложений, опенсорс библиотек. Хотя казалось бы, увеличение производительности разработчиков даже в 2 должны были привести к кратному росту всего, что они делают.
Что же мы видим в реальности? Много прототипов и 'я сделал игру за выходные', Но потом они уходят в небытие. Как будто написание кода не было ботлнеком.
Будем наблюдать. В качестве прототипирования и написания одноразового или неважного кода AI он действительно рулит и бибикает
Основная проблема умных телевизоров в том, что их ум стареет быстрее, чем техническая база самого телевизора.
Вот бы делали хорошие глупые телевизоры и подключаемы ai станции, которые можно менять хоть каждый второй год
А дайте ссылку на этот пакет документов. Я бы посмотрел на субстанцию того, что вы предлагаете. Техническую составляющую.
Просто если не нет, а весь проект это этот или такой же текст, то это буквально современный аналог пасты про грабить корованы.
Под такой текст хорошо бюджеты пилить или большого брата делать.
А в ваш она как встроена?
Очевидно эта этика будет задаваться владельцем системы (так же как и в случае Ютуба)
И в итоге это будет ещё одна труба этики государства. Не знаю как вы, но сейчас я лучше доверюсь этике Гугла.
Как по мне отличная тенденция. Мы уверенно движемся к тому, что учиться будут только те, кто действительно этого хочет. Все остальные будут читерить, потому что это становится максимально просто.
Го, как любой рантайм с гц, имеет проблемы с поддержкой низких латенси на одном хорошем уровне. Если вы ждёте 50мс ответа от базы, можно писать на чем угодно. А вот если захотите видеть сотни микросек, то го может начать быть проблемой
10 лет назад аудитории было поменьше
И на один запрос делалось сильно меньше
Нужно ли для компенсации этого все переписывать - вопрос спорный. Но ваш аргумент совсем слабый
Если бы ещё ydb sdk имели такую унифицированную опцию. В реальности даже в рамках одного гошного sdk эта настройка существует только для некоторых способов взаимодействия.
Я уже не говорю о том, что это именно table префикс. Используете топики (которые не бэкапятся, кстати) или более низкоуровневое API - вам не повезло, сами добавляйте префикс к названиям сущностей.
Было бы круто, если бы этот префикс стал глобальной настройкой sdk и полностью прозрачной для клиентского кода.