Мне кажется я понял теперь. Я не использую Copilot в таком виде, как ChatGPT для генерации рабочего кода. Только как умную подстановку и авто-дополнение, с чем он очень классно справляется. Если Copilot используется как ChatGPT, то я согласен с тем, что пользы реальной мало.
Простите, это конкретику не вносит. Если можно, уточните, пожалуйста, какие именно вещи Вы имеете ввиду?
Мне, как много пишущему, код интересно просто посмотреть на вещи под другим углом. МНе, например, продвинутый "IntelliSense" очень помогает. Весь мусор, который он может генерировать.. ну, просто игнорирую. И в итоге получается профит.
С какой стороны это может быть абузой? Мне не понятно. Можете, пожалуйста, пояснить эту точку зрения?
Может быть вам просто поменять компанию? Конечно, это зависит от вашего отношения к этой ситуации: нравится она или нет.
Я работал и в компаниях с российским и в компаниях с западным руководством. Многое зависит именно от той позиции, которую занимает руководство по данным вопросам. Что бы там каждый девелопер о себе ни думал, а в массе - мы животные и следуем за лидером. Маленькие люди подражают своим начальникам в действиях и образе мышления.
Мне, например, не нравилась. Я поменял, нашёл ту, где многое из перечисленных работает. Работать стало гораздо комфортнее. Но это мой личный опыт.
А мне интересно, как, будучи разработчиком, вы нашли клиентов, которые решили платить столько, что переключение на собственный новый бизнес не принесло потери в деньгах. Как вы нашли продажников, как заинтересовали их продавать ваш продукт?
Интересная статья. Спасибо. Однако у меня есть технические замечания. Выводы, указанные в статье, мне показались не основанными на представленных исследованиях. Возможно, это связано с тем, что статья является переводом. В ней говорится об оценке производительности, а затем о факторах, которые могут на нее влиять, но ни слова об исследовании этого влияния.
Я, как прошлый Вася, впечетлён хорошим изложением основных моментов мешающих взаимоотношениям на рабочем месте. Да и не только. Это точно, будучи вот таким Васей, пока мышление не поменяется, не понимаешь, почему как-то всё несрастается и к пониманию приходится продираться. Кажется, и всё говорится правильно, и делается правильно. Ведь так написано везде и умные ученые всё давно всё доказали. Но нет, не работает оно как написано в книжках.
Автор, спасибо застатью. Жаль что не сам её написал.
Получилось ли проверить initialExecutors? Мне тоже интересно, можно ли перед стартом джоба "прогреть" кластер, чтобы он поднял необходимое кол-во нодов, если требуется.
В нашем случае, файлы мы используем, главным образом, чтобы иметь оригинальные данные, которые сохраниются "как есть". А аналитику вcю делаем в BigQuery, предварительно выполнив обработку файлов, приведя их к некоему формату и добавив в BQ таблицы. Таким образом мы обрабатываем входящие данные, практически, сразу, как они попадают в Data Lake. Поэтому мы ушли сначала от Parquet к Avro, а потом от Avro к JSON. В нашем случае, данные поступают с сильно разной схемой от записи к записи. Буквально, в одном и том же файле должны находиться данные с разным кол-вом колонок (в том числе и во вложенных стркутурах). Хотя, я сейчас допускаю, что мы не нашли, как это сделать в Avro.
Если не сложно, можете, пожалуйста, рассказать немного подробнее, какого характера у Вас аналитические запросы к самим файлам и как часто вы их выполняете?
Привет, про evolution формат я не понял пункт. Он да, поддерживает, но не так как Avro, я написал, по-моему, об этом.
На счет сжатия, я не был бы так категоричен, как Вы. Но я не тестировал развернуто именно этот аспект. Вот тут есть сравнение (раздерл Preliminary tests): https://ericdraken.com/comparison-time-series-data-transport-formats/ Из которого видно, что нельзя быть категоричным, и что нужны всегда детали. Avro в этом сравнении, при определенных настройках, имеет лучшее сжатие, чем Parquet.
По-моему, креативных людей (и работают много и замотивированы, судя по описанию), которые пытаются смотреть на задачи шире и что-то привнести в проект, назвали "ноликами". Со всеми вытекающими...
Очень субъективный текст. Сложно с чем-то спорить, не потому, что это неправильно. Оно правильное, но не понятно к чему претензии в итоге.
Например, тестовые задания. У людей, которые пашут по 10-14 часов времени писать ЕЩЁ те товары задания нет. А "типа интересные" вообще нет. Но с другой стороны, что-то нужно дать для проверки навыка программирования и анализа задания. Не слишком сложные, но довольно открытое, чтобы увидеть как думает кандидат. Поэтому даёшь "не интересное" задание. Если человек его решил, то как минимум есть тема для дискуссии и понятно что замотивирован.
Интересно, будет ли относительно равноценной замена на LocalStorage, IndexedDB, или WebSQL?
Мне трудно оценить, т.к. не сильно продвинут в данных вещах. По идее, не должно быть проблемы, если и до этого кука создавалась для конкретного домена. Например, чтобы определить что это один и тот же физический юзер, который использует разные аккаунты. Конечно, если он прошаренный, он потрет и куки, и LocalStorage, и IndexedDB, и WebSQL. Но не все такие.
Да и если можно вопрос в догонку: а как прошаренного юзера определить, что он с одного и того же браузера/компа/места? Идеи?
Понравился Bullet train. Я сравнивал его с Vault. Мне нужен был сервер для хранения настроек (чтобы не в файлах и не в config-maps). Vault слишком громоздкий. Bullet train выглядит как очень быстрое и функциональное решение. Поднимай в Docker или k8s и «Вуаяля!». Имеет .NET клиент, что для нас важно. Но можно испоьзовать голый REST что позволяет его дергать еще и из скриптов. В общем, выглядит очень хорошо. Планируем ставить на проде.
А наш хозяин квартиры утверждает, что техника и после 25 лет, как новая. Если с ней аккуратно обращаться.
И кому верить? 🙃
Мне кажется я понял теперь. Я не использую Copilot в таком виде, как ChatGPT для генерации рабочего кода. Только как умную подстановку и авто-дополнение, с чем он очень классно справляется. Если Copilot используется как ChatGPT, то я согласен с тем, что пользы реальной мало.
Спасибо за уточнения.
Простите, это конкретику не вносит. Если можно, уточните, пожалуйста, какие именно вещи Вы имеете ввиду?
Мне, как много пишущему, код интересно просто посмотреть на вещи под другим углом. МНе, например, продвинутый "IntelliSense" очень помогает. Весь мусор, который он может генерировать.. ну, просто игнорирую. И в итоге получается профит.
С какой стороны это может быть абузой? Мне не понятно. Можете, пожалуйста, пояснить эту точку зрения?
А что именно для Вас является обузой?
Я смотрю на это иначе. Но, видимо, так.
Может быть вам просто поменять компанию? Конечно, это зависит от вашего отношения к этой ситуации: нравится она или нет.
Я работал и в компаниях с российским и в компаниях с западным руководством. Многое зависит именно от той позиции, которую занимает руководство по данным вопросам. Что бы там каждый девелопер о себе ни думал, а в массе - мы животные и следуем за лидером. Маленькие люди подражают своим начальникам в действиях и образе мышления.
Мне, например, не нравилась. Я поменял, нашёл ту, где многое из перечисленных работает. Работать стало гораздо комфортнее. Но это мой личный опыт.
Есть такие, но есть и другие. Им важно ЧТО именно они делают, а не просто код писать и быстрее свалить домой, ненавидя работу и коллег...
А мне интересно, как, будучи разработчиком, вы нашли клиентов, которые решили платить столько, что переключение на собственный новый бизнес не принесло потери в деньгах. Как вы нашли продажников, как заинтересовали их продавать ваш продукт?
Или была какая-то другая модель монетизации?
Вы GUI для редактирования OpenAPI не пробовали? Типа stoplight.io
Там, мне кажется, меньше возьни с поддержкой всей документации. Конфлюенс конечно работает, но это же как в Excel делать ML модель.
Интересная статья. Спасибо. Однако у меня есть технические замечания. Выводы, указанные в статье, мне показались не основанными на представленных исследованиях. Возможно, это связано с тем, что статья является переводом. В ней говорится об оценке производительности, а затем о факторах, которые могут на нее влиять, но ни слова об исследовании этого влияния.
Я, как прошлый Вася, впечетлён хорошим изложением основных моментов мешающих взаимоотношениям на рабочем месте. Да и не только. Это точно, будучи вот таким Васей, пока мышление не поменяется, не понимаешь, почему как-то всё несрастается и к пониманию приходится продираться. Кажется, и всё говорится правильно, и делается правильно. Ведь так написано везде и умные ученые всё давно всё доказали. Но нет, не работает оно как написано в книжках.
Автор, спасибо застатью. Жаль что не сам её написал.
Получилось ли проверить initialExecutors? Мне тоже интересно, можно ли перед стартом джоба "прогреть" кластер, чтобы он поднял необходимое кол-во нодов, если требуется.
В нашем случае, файлы мы используем, главным образом, чтобы иметь оригинальные данные, которые сохраниются "как есть". А аналитику вcю делаем в BigQuery, предварительно выполнив обработку файлов, приведя их к некоему формату и добавив в BQ таблицы. Таким образом мы обрабатываем входящие данные, практически, сразу, как они попадают в Data Lake. Поэтому мы ушли сначала от Parquet к Avro, а потом от Avro к JSON. В нашем случае, данные поступают с сильно разной схемой от записи к записи. Буквально, в одном и том же файле должны находиться данные с разным кол-вом колонок (в том числе и во вложенных стркутурах). Хотя, я сейчас допускаю, что мы не нашли, как это сделать в Avro.
Если не сложно, можете, пожалуйста, рассказать немного подробнее, какого характера у Вас аналитические запросы к самим файлам и как часто вы их выполняете?
А можно пассивно-агресивный тон убрать из дискуссии?
Спасибо за указание неточности в тесте. Изучу внимательнее этот момент. Судя по еще и этой статье https://www.adaltas.com/en/2021/03/22/performance-comparison-of-file-formats/ разница не столь существенна. Возможно, в каких-то сценариях важна. У вас это важный момент?
Привет, про evolution формат я не понял пункт. Он да, поддерживает, но не так как Avro, я написал, по-моему, об этом.
На счет сжатия, я не был бы так категоричен, как Вы. Но я не тестировал развернуто именно этот аспект. Вот тут есть сравнение (раздерл Preliminary tests): https://ericdraken.com/comparison-time-series-data-transport-formats/ Из которого видно, что нельзя быть категоричным, и что нужны всегда детали. Avro в этом сравнении, при определенных настройках, имеет лучшее сжатие, чем Parquet.
По-моему, креативных людей (и работают много и замотивированы, судя по описанию), которые пытаются смотреть на задачи шире и что-то привнести в проект, назвали "ноликами". Со всеми вытекающими...
Конечно, стинные детали мне не известны.
Очень субъективный текст. Сложно с чем-то спорить, не потому, что это неправильно. Оно правильное, но не понятно к чему претензии в итоге.
Например, тестовые задания. У людей, которые пашут по 10-14 часов времени писать ЕЩЁ те товары задания нет. А "типа интересные" вообще нет. Но с другой стороны, что-то нужно дать для проверки навыка программирования и анализа задания. Не слишком сложные, но довольно открытое, чтобы увидеть как думает кандидат. Поэтому даёшь "не интересное" задание. Если человек его решил, то как минимум есть тема для дискуссии и понятно что замотивирован.
Сдается мне, что с Kafka и KSQL вы залочены на кафку.
Мне трудно оценить, т.к. не сильно продвинут в данных вещах. По идее, не должно быть проблемы, если и до этого кука создавалась для конкретного домена. Например, чтобы определить что это один и тот же физический юзер, который использует разные аккаунты. Конечно, если он прошаренный, он потрет и куки, и LocalStorage, и IndexedDB, и WebSQL. Но не все такие.
Да и если можно вопрос в догонку: а как прошаренного юзера определить, что он с одного и того же браузера/компа/места? Идеи?
Кто-нибудь его «очернить» может?