Ну такое. Я покодил с Copilot в реальном проекте пару месяцев. Оно конечно неплохо делает автодополнение отдельных строчек, но написать что-то сложнее не может почти никогда.
В общем, забавно, но какой-то ценности я так и не увидел даже на $10/месяц
Сижу в Киеве, много друзей в Киеве в разных районах. За достоверность того что вижу и слышу не ручаюсь, но могу в личку ответить на вопросы (в комментах не хочу, это повышает шанс сноса статьи)
В статье ещё не упомянут важный фактор, который, имхо, тоже повышает приоритет мелких тестов: стоимость фикса.
Unit-тест, написанный разработчиком, сломается ещё на его локальной машине (при рефакторинге, например), и будет починен ещё до попадания кода в репозиторий
В клиент-серверной или сервисной архитектуре тест на API (написанный уже скорее всего QA-автоматизатором) сломается до того, как его попытаются интегрировать в себя другие части системы.
А E2E тест выполняющийся на околопродакшновом окружении фиксить вообще тяжело. Необходимо будет понять, что из частей системы вообще сломалось, затем воспроизвести это поведение поближе к девелоперам (что может быть не очень просто при росте количества шагов в E2E тесте), починить, пройти ревью/мержи/делпой на нужное окружение и дождаться следующего запуска тех самых E2E тестов.
Автоматизация тестирования - процесс написания кода на языке программирования для проверки работоспособности приложения методом выполнения некоторых последовательностей действий над частями приложения, которые в идеале должны приводить к ожидаемым результатам.
Частями приложения в зависимости от типа теста могут быть: одиночные функции, API методы, интерфейс.
Где и как такие тесты должны выполняться (и кем должны имплементироваться) - зависит от многих факторов, в частности от той самой пирамиды: насколько легко пишется тест, насколько долго он выполняется, насколько сложное окружение ему нужно для выполнения.
Если в колонке дата/время не на последнем месте, то проверьте
Добавлю от себя исключение из недавнего на работе: если индекс не для сравнения, а для сортировки, то он вполне может начинаться с даты. `ORDER BY date, id` может быть использован для досортировки данных с одинаковой датой (это полезно, например, для пагинации, чтобы одни и те же строки не попали на разные страницы)
Хотя всё это не важно. Важнее то, что при попытке решить уравнение относительно константы, скорее всего окажется, что второе решение будет переменной, а не константой.
Не разбираюсь в физике почти совсем, быстро погуглил. Там же есть мнимая единица в уравнении? Т.е. одно из значений h будет комплексным, что не особо интересно для реальности. И даже если бы там было не i, то вполне вероятно, что из двух решений h одно было бы отрицательным, что тоже не особо интересно.
В Украине нет банальной IKEI (пару пунктов выдачи в Киеве сложно назвать присутствием)
Не ради спора, вдруг вам поможет - уже больше полугода есть магазин в ТРЦ Блокбастер. У меня уже полквартиры икеей заставлено - жильё недавно обустраивал.
Индустрия же так не работает. Здесь всё обусловлено эффективностью. Если что-то создаёт проблем больше, чем решает - это не используют.
В принципе этого тезиса достаточно. Добавлю, что эффективность это что-то среднее между "удобством программиста" и "количеством багов". Остальное же, о чём вы говорите - это субъективные рассуждения об удобстве, только почему-то ваше удобство - оно правильное, а удобство остальных - это фанатизм и методички.
За сим раскланиваюсь, у меня нет цели вас переубедить, я лишь оставил пару комментов о реальных, а не выдуманных вами возможностях работы с ошибками для тех, кто возможно доберётся сюда почитать
Через anyhow вы типы оборачиваете, а не затираете, тип ошибки можно восстановить. Я могу согласиться, что это работает не очень удобно, поэтому есть и другой вариант.
Можно описать свой собственный большой enum с ошибками, и задать правила конвертации всех возможных в него. С такими правилами ? будет работать автоматически из библиотечных ошибок в ваши, и при этом у вас всегда перед глазами будет полный список вообще всех ошибок, которые могут вылезти.
Ну такое. Я покодил с Copilot в реальном проекте пару месяцев. Оно конечно неплохо делает автодополнение отдельных строчек, но написать что-то сложнее не может почти никогда.
В общем, забавно, но какой-то ценности я так и не увидел даже на $10/месяц
GSC Game World показала более важный ролик - новые дневники разработки.
Так может в этом и суть перфоманса языка? Суметь оптимизировать наивный код среднестатистического девелопера
И моё любимое Дуров не имеет никакого отношения к TON
Кроме 100500 форков биткоина вот небольшой список из топовых
Ripple https://github.com/ripple/rippled
EOS https://github.com/EOSIO/eos
Stellar https://github.com/stellar/stellar-core
Monero https://github.com/monero-project/monero
А вообще в крипте доминирует даже не rust, а go. А вот про агду не слышал, видимо совсем в стартапах.
Кстати, даже хаскель есть - в Cardano https://github.com/input-output-hk/cardano-node
Но ведь клиенты из России налогами спонсируют эту войну.
Сижу в Киеве, много друзей в Киеве в разных районах. За достоверность того что вижу и слышу не ручаюсь, но могу в личку ответить на вопросы (в комментах не хочу, это повышает шанс сноса статьи)
Тестировать можно и вручную, поэтому тесты, выполняемые скриптами, называют автотестами.
В идеале, потому что, как написано в статье, в реальности тесты высокого уровня могут быть устаревшими, плохо работающими и т.п.
В статье ещё не упомянут важный фактор, который, имхо, тоже повышает приоритет мелких тестов: стоимость фикса.
Unit-тест, написанный разработчиком, сломается ещё на его локальной машине (при рефакторинге, например), и будет починен ещё до попадания кода в репозиторий
В клиент-серверной или сервисной архитектуре тест на API (написанный уже скорее всего QA-автоматизатором) сломается до того, как его попытаются интегрировать в себя другие части системы.
А E2E тест выполняющийся на околопродакшновом окружении фиксить вообще тяжело. Необходимо будет понять, что из частей системы вообще сломалось, затем воспроизвести это поведение поближе к девелоперам (что может быть не очень просто при росте количества шагов в E2E тесте), починить, пройти ревью/мержи/делпой на нужное окружение и дождаться следующего запуска тех самых E2E тестов.
Автоматизация тестирования - процесс написания кода на языке программирования для проверки работоспособности приложения методом выполнения некоторых последовательностей действий над частями приложения, которые в идеале должны приводить к ожидаемым результатам.
Частями приложения в зависимости от типа теста могут быть: одиночные функции, API методы, интерфейс.
Где и как такие тесты должны выполняться (и кем должны имплементироваться) - зависит от многих факторов, в частности от той самой пирамиды: насколько легко пишется тест, насколько долго он выполняется, насколько сложное окружение ему нужно для выполнения.
Добавлю от себя исключение из недавнего на работе: если индекс не для сравнения, а для сортировки, то он вполне может начинаться с даты. `ORDER BY date, id` может быть использован для досортировки данных с одинаковой датой (это полезно, например, для пагинации, чтобы одни и те же строки не попали на разные страницы)
Хотя всё это не важно. Важнее то, что при попытке решить уравнение относительно константы, скорее всего окажется, что второе решение будет переменной, а не константой.
Не разбираюсь в физике почти совсем, быстро погуглил. Там же есть мнимая единица в уравнении? Т.е. одно из значений h будет комплексным, что не особо интересно для реальности. И даже если бы там было не i, то вполне вероятно, что из двух решений h одно было бы отрицательным, что тоже не особо интересно.
Я вижу тут только два разумных варианта, как расставить скобки: (1/3) * (1/2) или ((1/3)*1)/2. Результат от этого не изменится
Сами смешивайте обедненный уран с антиураном
Нет, всё ж поспорю с вот этим, хотя скорее для альтернативного мнения, чем лично с вами.
Три года в Киеве живу с Донецкой пропиской - 0 проблем. В том числе с путешествиями за границу.
Не ради спора, вдруг вам поможет - уже больше полугода есть магазин в ТРЦ Блокбастер. У меня уже полквартиры икеей заставлено - жильё недавно обустраивал.
Спасибо за пояснение по терминологии. Хоть это ничего и не меняет в обсуждении, но мне не помешает для общего развития
В принципе этого тезиса достаточно. Добавлю, что эффективность это что-то среднее между "удобством программиста" и "количеством багов". Остальное же, о чём вы говорите - это субъективные рассуждения об удобстве, только почему-то ваше удобство - оно правильное, а удобство остальных - это фанатизм и методички.
За сим раскланиваюсь, у меня нет цели вас переубедить, я лишь оставил пару комментов о реальных, а не выдуманных вами возможностях работы с ошибками для тех, кто возможно доберётся сюда почитать
Через anyhow вы типы оборачиваете, а не затираете, тип ошибки можно восстановить. Я могу согласиться, что это работает не очень удобно, поэтому есть и другой вариант.
Можно описать свой собственный большой enum с ошибками, и задать правила конвертации всех возможных в него. С такими правилами
?будет работать автоматически из библиотечных ошибок в ваши, и при этом у вас всегда перед глазами будет полный список вообще всех ошибок, которые могут вылезти.В реальных проектах как раз второй подход и используется. Например https://github.com/openethereum/openethereum/blob/main/crates/accounts/ethstore/src/error.rs