Обозреватель The Register Томас Клабёрн рассказал, что за семь недель и 337 коммитов собрал
Забыл упомянуть количество строк кода - это же самое главное у них)
Отношение профессиональных разработчиков к вайб-кодингу Клабёрн сравнивает с реакцией академических музыкантов 1970-х на панк и рэп: возмущает не результат, а то, что исполнительское мастерство перестаёт быть обязательным условием.
От нелепых сравнений бездумное написание кода с помощью чат-ботов не станет лучше, хотя им конечно очень хочется) тут прям профнепригодностью попахивает, журналист всерьёз сравнивает эти две вещи
А вот менеджеры очень воодушевлены. Они почему-то видят какую-то добавочную ценность в том что можно быстро получить какой-то левый код. Много-много буковок кода
Так вот в чём причина того, что в каждой второй статье про очередную "ии"-поделку обязательно упоминается количество строк кода) буквально как важнейший показатель
Расплодилось великое множество объектно-ориентированных языков: C++, Java, C#, JavaScript
На последнем очень хочется остановиться) можно подумать, что это ошибка, но нет, дальше в списке будет и TypeScript, так что нет, автор явно намеренно записал JavaScript в расплодившиеся объектно-ориентированные языкис начала 90-х.
А теперь следим за руками:
Официальная дата запуска JavaScript - 4 декабря 1995 года.
Классы в JavaScript появились в ECMAScript 2015 (ES6), выпущенном в июне 2015 года.
И даже в таком случае это тоже функции, объявляемые иначе, о чём прямо сказано на MDN - Classes are in fact “special functions”, and just as you can define function expressions and function declarations, a class can be defined in two ways: a class expression or a class declaration
Ничего себе, расплодившийся с начала 90-х ООПшный язык, в котором до 2015 года даже не существовало ключевого слова class) Ну и смысл читать дальше после подобных заявлений? Человек же явно не понимает, о чём говорит
Делаю ставку что генеративный поиск станет основным каналом выбора у покупателей и поиска информации в целом
Серьёзно? Лично вы спрашивали для себя(не по работе) у нейронки, какой товар или бренд лучше? При том, что в большинстве своём люди-то сами не знают, какой лучше и почему. Вокруг "типа ИИ" много ставок на то, что он что-то там революционно изменит, но чтобы люди покупки совершали на основе его рекомендаций - совсем уж грустно.
Как металлообрабатывающий завод ускорил выполнение задач в 3 раза с помощью Кайтена и ChatGPT
а дальше ни слова про ускорение ВЫПОЛНЕНИЯ задач) только про их постановку. начальникам тоже про ускорение именно времени выполнения задач рассказываете?
На своем опыте работы в разных компаниях ни разу не встречал случаев, когда зарплаты друг перед другом светят. Подозреваю, что данное предложение сгенерировано ИИ.
А если на своих работах с ребятами, с которыми складывалось близкое общение, мы свободно обсуждали зпшки, несмотря на запреты руководства - то что? По вашей логике уже ваше предложение сгенерировано ИИ?
у вас опечатки в слове "субъективно", так как часть неудобных вопросов вы всё же опустили. зачем по соц.сетям распространять "более новую" версии программы, кода которой не существует в открытой репе, при том, что под капотом используется чужое решение, как раз-таки из полностью открытой репы zapret? при том, что обходы блокировок ежедневно ломаются - это буквально подталкивание с скачиванию именно новой версии, с внутренностями которой нет возможности ознакомиться
ага, а снесли-то все обсуждаемые автором модули почему?) ровно как и почему версии, скомпилированные в .exe, отстают от тех, что в открытой репе? что за "секреты" в закрытой репе, зачем?) полагаю, на эти вопросы вы не в состоянии ответить, ведь автор "обиделся", и этого достаточно, чтобы на неудобные вопросы не отвечать
Спасибо, интересно что ваши цифры совпадают 5x это уже паттерн, не случайность
это заговор!! а если серьёзно, то тот же тайпскрипт уже вовсю переписывают на rust, потому что rust по дефолту кратно быстрее. и вроде как следующая мажорная версия уже будет на нём. не понятно, в чём ваше открытие
из какой коробки?) первые скрипты методами были прямо из Node.js? полагаю, что нет. их писали либо вы, либо чат-бот. то есть вы отдали первый кривой скрипт чат-боту, тот переписал его под rust, потом компилятор rust нашёл ошибки связанные с типами(правда не указано, в чём именно, но видимо в первой попытке чат-бота выдать что-то на rust), они были исправлены - и вуаля, "Галя, у нас победа". А что мешало-то юзать тайпскрипт для строгой системы типов в Node.js, чтобы вообще не столкнуться с такой проблемой?)
Ну слушайте, это же всё ещё зелёный, неопытный чувак, просто после курсов. Я во время обучения если и видел вообще инфу о том, что такое перегрузка функции, то поспешил забыть как страшный сон) потому что и так много всего непонятного и сложного вываливается в сжатые сроки. И только потом, уже на работе, причём далеко не на первой, мне понадобилось действительно вспомнить об этом подходе
Накидаю ещё вопросов вдогонку. Допустим у нас имеется выпадающий список на 20 элементов, вы победили. Как он должен вести себя, если сам элемент, открывающий выпадающий список, находится посередине страницы? Открыться в любую сторону с выносом элементов списка за пределы экрана? Открыться с обрезанием до границ экрана? Как такой список поведёт себя на экране в 15 дюймов с масштабированием в 50%? Если вы об этом не думали, предлагая свои хотелки, то вряд ли вы вообще фронтенд)
Короткий же выпадающий список исключает все эти проблемы, потому что ему так или иначе хватит места открыться в какую-либо сторону
Именно поэтому в таком случае вы вписываете первые буквы, как вам кажется, подходящего хаба в поиск, и находите подходящий результат. Если хабов 100, и список пролистывается не с 4 элементами на экране, а с 20 - что-то принципиально изменится разве? Вам всё ещё придётся просмотреть все 100, с таким подходом, разве что проскроллить нужно будет кратно меньше. Зато тем, кто привык пользоваться поиском, придётся теперь смотреть на огроменный вываливающийся список.
А если 1000 будет, что тогда? Тоже будете говорить "хочу их видеть или просмотреть большим списком"? Поиск вашу проблему решил, названия хабов +- кореллируют с названиями, которые мы используем в реальной жизни, с возможными тематиками. Остальное уже ваши придирки/хотелки чисто под себя
Да, есть поиск, и он помогает — можно не скроллить, а сразу напечатать. Но откуда мне знать, что именно печатать, если разработчики решили выдавать список из 100+ элементов порциями по 4 штуки?
Простите, ЧТО?) Речь же о настройках вашей публикации. Вы понятия не имеете, о чём пишете, и поэтому вам нужно увидеть весь список, прежде чем начать вписывать в поле поиска название подходящего хаба? И виноват в этом интерфейс хабра, всё так?
Коллеги из западных команд говорят, что скорость разработки выросла в два раза. Не в полтора — в два. Это не хайп, это реальные цифры от реальных людей.
в 100500 раз!! главное в конце добавить, что это "реальные цифры от реальных людей", для большей убедительности) все ваши заявления про "без впн, без облака" и прочее тоже пустые слова, без ссылки на репу
Это вы не видели ещё самое бестолковое) на пару недель загремел в другую команду, помочь с релизом MVP. Так у них в проекте(при том, что это MVP и надо вроде как побыстрее) буквально на каждый, даже самый мизерный компонент, написан бесполезный тест на jest, который проверяет, что компонент рендерится. Без различных комбинаций пропсов, без пограничных случаев или исключений, и все такие написанные ранее тесты перед коммитом должны пройти.
Казалось бы, ну тесты и тесты, ну запускаются там себе перед коммитом. Проблемы начались тогда, когда компонент-заглушка(на который, разумеется, написан свой тест) перестал быть таковым - в нём появился хук из RTK, а именно useAppSelector: это сломало тесты, ведь jest не знает, что это за метод, какие значения он отдаст в компонент. Теперь необходимо идти в поломанный бесполезный тест и мокать в нём хук, а так же значения, которые он вернёт для теста.
И так в каждом бесполезном тесте компонента, где ранее не использовался useAppSelector, но вдруг стал. По итогу получается какая-то обезьянья работа: тратить время на починку того, что не несёт в себе никакой пользы. Причём в будущем проект будет покрываться интеграционными тестами, что лишает написание обсуждаемых выше юнит-тестов на jest какого-либо смысла. Но тем не менее, единственным фронтенд-разработчиком на этом проекте(если не считать тех, кого время от времени присылают на помощь, как меня) тесты упорно пишутся
Неприятен тон статьи, как будто разработчики - ограниченные/инфантильные существа и их нужно "знакомить с реальностью"
Базовый тон статьи любого менеджера)
Буквально заголовок статьи сразу кричит о том, что происходят стадии принятия, как у горя - ну то есть от этого никуда не деться, это "новая реальность", и всё что можно с этим делать, так это принять. Но это не так, это ваша, менеджеров, желаемая реальность, где все всё делают за 5 минут с чат-ботом. И под неё вы пытаетесь всех подогнать, потому что эйфория и отсутствие критического мышления. Выглядит всё так, будто именно вам нужно пройти стадии принятия действительности, но проще же считать идиотами всех вокруг, кроме себя, в особенности подчинённых
Забыл упомянуть количество строк кода - это же самое главное у них)
От нелепых сравнений бездумное написание кода с помощью чат-ботов не станет лучше, хотя им конечно очень хочется) тут прям профнепригодностью попахивает, журналист всерьёз сравнивает эти две вещи
Так вот в чём причина того, что в каждой второй статье про очередную "ии"-поделку обязательно упоминается количество строк кода) буквально как важнейший показатель
На последнем очень хочется остановиться) можно подумать, что это ошибка, но нет, дальше в списке будет и TypeScript, так что нет, автор явно намеренно записал JavaScript в расплодившиеся объектно-ориентированные языки с начала 90-х.
А теперь следим за руками:
Официальная дата запуска JavaScript - 4 декабря 1995 года.
Классы в JavaScript появились в ECMAScript 2015 (ES6), выпущенном в июне 2015 года.
И даже в таком случае это тоже функции, объявляемые иначе, о чём прямо сказано на MDN -
Classes are in fact “special functions”, and just as you can define function expressions and function declarations, a class can be defined in two ways: a class expression or a class declarationНичего себе, расплодившийся с начала 90-х ООПшный язык, в котором до 2015 года даже не существовало ключевого слова class) Ну и смысл читать дальше после подобных заявлений? Человек же явно не понимает, о чём говорит
Серьёзно? Лично вы спрашивали для себя(не по работе) у нейронки, какой товар или бренд лучше? При том, что в большинстве своём люди-то сами не знают, какой лучше и почему. Вокруг "типа ИИ" много ставок на то, что он что-то там революционно изменит, но чтобы люди покупки совершали на основе его рекомендаций - совсем уж грустно.
Ваше время стоит 0$?
Заголовок
а дальше ни слова про ускорение ВЫПОЛНЕНИЯ задач) только про их постановку. начальникам тоже про ускорение именно времени выполнения задач рассказываете?
ну то есть не надо показывать, потому что люди плохие, а не потому что приложение скорее всего действительно шлак?) как ловко
А если на своих работах с ребятами, с которыми складывалось близкое общение, мы свободно обсуждали зпшки, несмотря на запреты руководства - то что? По вашей логике уже ваше предложение сгенерировано ИИ?
у вас опечатки в слове "субъективно", так как часть неудобных вопросов вы всё же опустили. зачем по соц.сетям распространять "более новую" версии программы, кода которой не существует в открытой репе, при том, что под капотом используется чужое решение, как раз-таки из полностью открытой репы zapret? при том, что обходы блокировок ежедневно ломаются - это буквально подталкивание с скачиванию именно новой версии, с внутренностями которой нет возможности ознакомиться
ага, а снесли-то все обсуждаемые автором модули почему?) ровно как и почему версии, скомпилированные в .exe, отстают от тех, что в открытой репе? что за "секреты" в закрытой репе, зачем?) полагаю, на эти вопросы вы не в состоянии ответить, ведь автор "обиделся", и этого достаточно, чтобы на неудобные вопросы не отвечать
это заговор!! а если серьёзно, то тот же тайпскрипт уже вовсю переписывают на rust, потому что rust по дефолту кратно быстрее. и вроде как следующая мажорная версия уже будет на нём. не понятно, в чём ваше открытие
из какой коробки?) первые скрипты методами были прямо из Node.js? полагаю, что нет. их писали либо вы, либо чат-бот. то есть вы отдали первый кривой скрипт чат-боту, тот переписал его под rust, потом компилятор rust нашёл ошибки связанные с типами(правда не указано, в чём именно, но видимо в первой попытке чат-бота выдать что-то на rust), они были исправлены - и вуаля, "Галя, у нас победа". А что мешало-то юзать тайпскрипт для строгой системы типов в Node.js, чтобы вообще не столкнуться с такой проблемой?)
Ну слушайте, это же всё ещё зелёный, неопытный чувак, просто после курсов. Я во время обучения если и видел вообще инфу о том, что такое перегрузка функции, то поспешил забыть как страшный сон) потому что и так много всего непонятного и сложного вываливается в сжатые сроки. И только потом, уже на работе, причём далеко не на первой, мне понадобилось действительно вспомнить об этом подходе
Всякий мусор принесли, а Хекслет - нет
Накидаю ещё вопросов вдогонку. Допустим у нас имеется выпадающий список на 20 элементов, вы победили. Как он должен вести себя, если сам элемент, открывающий выпадающий список, находится посередине страницы? Открыться в любую сторону с выносом элементов списка за пределы экрана? Открыться с обрезанием до границ экрана? Как такой список поведёт себя на экране в 15 дюймов с масштабированием в 50%? Если вы об этом не думали, предлагая свои хотелки, то вряд ли вы вообще фронтенд)
Короткий же выпадающий список исключает все эти проблемы, потому что ему так или иначе хватит места открыться в какую-либо сторону
Именно поэтому в таком случае вы вписываете первые буквы, как вам кажется, подходящего хаба в поиск, и находите подходящий результат. Если хабов 100, и список пролистывается не с 4 элементами на экране, а с 20 - что-то принципиально изменится разве? Вам всё ещё придётся просмотреть все 100, с таким подходом, разве что проскроллить нужно будет кратно меньше. Зато тем, кто привык пользоваться поиском, придётся теперь смотреть на огроменный вываливающийся список.
А если 1000 будет, что тогда? Тоже будете говорить "хочу их видеть или просмотреть большим списком"? Поиск вашу проблему решил, названия хабов +- кореллируют с названиями, которые мы используем в реальной жизни, с возможными тематиками. Остальное уже ваши придирки/хотелки чисто под себя
Простите, ЧТО?) Речь же о настройках вашей публикации. Вы понятия не имеете, о чём пишете, и поэтому вам нужно увидеть весь список, прежде чем начать вписывать в поле поиска название подходящего хаба? И виноват в этом интерфейс хабра, всё так?
в 100500 раз!! главное в конце добавить, что это "реальные цифры от реальных людей", для большей убедительности) все ваши заявления про "без впн, без облака" и прочее тоже пустые слова, без ссылки на репу
Это вы не видели ещё самое бестолковое) на пару недель загремел в другую команду, помочь с релизом MVP. Так у них в проекте(при том, что это MVP и надо вроде как побыстрее) буквально на каждый, даже самый мизерный компонент, написан бесполезный тест на jest, который проверяет, что компонент рендерится. Без различных комбинаций пропсов, без пограничных случаев или исключений, и все такие написанные ранее тесты перед коммитом должны пройти.
Казалось бы, ну тесты и тесты, ну запускаются там себе перед коммитом. Проблемы начались тогда, когда компонент-заглушка(на который, разумеется, написан свой тест) перестал быть таковым - в нём появился хук из RTK, а именно useAppSelector: это сломало тесты, ведь jest не знает, что это за метод, какие значения он отдаст в компонент. Теперь необходимо идти в поломанный бесполезный тест и мокать в нём хук, а так же значения, которые он вернёт для теста.
И так в каждом бесполезном тесте компонента, где ранее не использовался useAppSelector, но вдруг стал. По итогу получается какая-то обезьянья работа: тратить время на починку того, что не несёт в себе никакой пользы. Причём в будущем проект будет покрываться интеграционными тестами, что лишает написание обсуждаемых выше юнит-тестов на jest какого-либо смысла. Но тем не менее, единственным фронтенд-разработчиком на этом проекте(если не считать тех, кого время от времени присылают на помощь, как меня) тесты упорно пишутся
Базовый тон статьи любого менеджера)
Буквально заголовок статьи сразу кричит о том, что происходят стадии принятия, как у горя - ну то есть от этого никуда не деться, это "новая реальность", и всё что можно с этим делать, так это принять. Но это не так, это ваша, менеджеров, желаемая реальность, где все всё делают за 5 минут с чат-ботом. И под неё вы пытаетесь всех подогнать, потому что эйфория и отсутствие критического мышления. Выглядит всё так, будто именно вам нужно пройти стадии принятия действительности, но проще же считать идиотами всех вокруг, кроме себя, в особенности подчинённых
Сколько всего люди готовы придумать, лишь бы не принимать тот факт, что чат-боты только лишь срут в разработку)