Рекурсивные скачиватели зависимостей - зло?
То, что куча веб-прогеров макаки, не должно останавливать развитие нормальных тулзов. Если проблемные проекты опен-сорс, зафигачь патч, избавляющий от зависимости.
Во-вторых, разработчики перестают понимать, что каждая лишняя библиотека увеличивает технический долг проекта.Как и любой лишний велосипед.
именно. Причём велосипед приходиться поддерживать тебе лично. А если ты выбирал готовые библиотеки не наобум, а по принципу живучести сообщества, то поддержку вовремя ты получишь от разработчиков этих библиотек.
When I choose <insert gigantic ORM name here>, I am choosing not to think. The ORM does all the thinking for me, and I assume they did it right. I outsourced my thinking. The unfortunate side-effect of this Non Thinking is that I now have to do lots of manual reading and learning of what the right way of thinking is.
http://samsaffron.com/archive/2012/01/16/that-annoying-inser...
Вместо ORM можно подставить любой фреймворк.
знаешь, сколько раз смотрел на многокилометровые сырцы библиотек, и каждый раз понимал - что прочитать исходники и понять их - дело гораздо более быстрое и выгодное, чем написание аналогов собственноручно. Тем более что до половины тонкостей, замеченных в исходниках, я самостоятельно додуматься не мог
Есть два основных способа добавлять зависимости в проект - комитить их в source control и использовать спец тулзы для рекурсивной скачки зависимостей - bundler для ruby, maven для джавы, npm для nodejs. В последнее время мне кажется, что такие тулзы - безусловное злоСпособов больше, такие тулзы --- зло.
Способов больше
Я могу назвать еще сабмодули гита и какие-нибудь самодельные мейкфайлы которые делают curl + tar. А ты что имеешь в виду?
на ночь читаешь исходники?
> > Добавлять зависимости становится слишком легко
> зафигачь патч, избавляющий от зависимости
Замечу, что избавляться от зависимостей при этом не становится легко
> зафигачь патч, избавляющий от зависимости
Замечу, что избавляться от зависимостей при этом не становится легко
Во-вторых, разработчики перестают понимать, что каждая лишняя библиотека увеличивает технический долг проекта. Крайний пример - это разработка на ruby on rails в стиле обновили гем, отвалился другой гем, обновили тот гем, отвалился третий.Разработчики на Ruby они такие, да. Отсюда скорее нужно сделать вывод, что Ruby - зло.
Отсутствие менеджера зависимостей, как правило, слишком слабое препятствие для добавления новых либ, чтобы остановить кого-то от добавления новой либы.
Зато, отличное препятствие для, например, обновления этой либы.
Зато, отличное препятствие для, например, обновления этой либы.
Если юзаешь нестандартную либу надо знать, как она устроена и что от неё ждать. Совсем уж популярные и распространённые я не читаю, всё равно лучше не найду, а проверены они гигантским количеством компьютерочасов работы.
А почему кстати все эти программы переписываются каждый раз на каждом новом появляющемся языке? Почему npm, pip, composer, bundler - это разные программы? Есть ли на это какая-то причина?
Мне в этом видится просто велосипедизм.
Мне в этом видится просто велосипедизм.
Зато, отличное препятствие для, например, обновления этой либы.Только если либа тянет за собой пачку либ для полноценного функционирования, а некоторые либы из этой пачки тащат за собой дополнительные либы. Если же граф зависимостей не такой сложный, то никакое это не препятствие. Гораздо серьёзное препятствие - отсутствие автоматических тестов.
Гораздо серьёзное препятствие - отсутствие автоматических тестов.А компелятор не поможет?
А компелятор не поможет?мне недавно (1.5-2 месяца назад) пришлось обновить библиотеку primefaces в одном из веб-проектов, т.к. в предыдущей версии не было нужного функционала. И только на этой неделе обнаружилось, что под ie7 часть функционала вообще не работает (сборка в продакшн ушла, даже не на прошлой неделе). Посидел часок-другой, локализовал и исправил проблему, но хз когда выложат патч, т.к. решили уже повесить для древнеосликоедов сообщение с просьбой обновиться. Проблема была всего-лишь в одном месте джаваскриптов библиотеки: к строковому объекту обращались как к массиву.
В принципе, к авторам библиотеки никаких претензий: они еще в предыдущей версии отказались от поддержки ie7, хоть функционал и работал корректно (в основном, внешний вид портился). К тестерам нашим тоже особо не придерёшься: они не макаки чтобы под каждой версией каждого браузера тестировать (под 2-3 браузерами функционал точно протыкивался). Была бы под руками платформа с множественными тестами под различные браузеры - обновлялись бы регулярно, хоть и делаем это вручную.
ie7
Гораздо серьёзное препятствие - отсутствие автоматических тестов.Это препятствие для любых изменений, а не только же для обновления либ.
Кроме того, к вопросу почему каждый язык стремится изобрести свою рекурсивную скачивалку (кто-то недавно поднимал его кажется). В этих "рекурсивных скачивателях зависимостей" сама рекурсивность - самый маленький кусочек функционала же.
Основное - сборка зависимостей+кода в что-то исполняемой, запуск тестов, деплой, итд.
Я работал с кастом системами сборки, где было просто скачивание без рекурсивности. В них отчетливо не хватало рекурсивности (добавление зависимости в какой-нибудь аццки shared модуль в низу иерархии зависимостей ломало все подряд). При этом с проблемой даймондов там не то что бы было сильно легче (основная проблема же подобрать такой набор версий, которые уживутся друг с другом, а прописывание версий в конфиг как правило больших усилий не занимает).
Работал с системами где не было ни скачивания ни рекурсивности. Все зависимости тупо были сложены в vcs. Замечательной особенностью было то, что имена зависимостей перечислялись множество раз в различных конфигурационных файлах (список чего куда деплоить, список чего с счем запускать, итд и добавить новую зависимость было просто застрелиться (час-два брождения по конфигам и потом еще trial-and-error деплои и проверки рабочести).
Количество зависимостей при этом было далеко за сотню, и, наверное, даже не одну. Там встречались зависимости древних неидентифицируемых версий. Там встречались разные версии одной и той же либы. Там даже встречались зависимости, которые были пропатчены при добавлении непонятными патчами.
Проблема была всего-лишь в одном месте джаваскриптов библиотеки: к строковому объекту обращались как к массиву.Компилятор с этим справится.
На моей практики были похожие случаи, в js библиотеке поменяли просто название метода, мы обновились, у нас молча отвалилась редко вызываемая функциональность. Для .Net программистов такая ситуация вызывает огромное недоумение, как в современном языке может быть такое.
Это препятствие для любых изменений, а не только же для обновления либ.Вы так говорите, как будто наличие автоматических тестов устраняет препятствие к любым изменением.
На моей практики были похожие случаи, в js библиотеке поменяли просто название метода, мы обновились, у нас молча отвалилась редко вызываемая функциональность. Для .Net программистов такая ситуация вызывает огромное недоумение, как в современном языке может быть такое.Ты не учитываешь что если бы в браузерах API было бы типизированным то они не развились бы до таких классных платформ какими они являются сейчас. Развитие браузеров основывалось на том что разные вендоры добавляли разные фичи, плохие фичи эволюционно отмирали, хорошие переходили в другие браузеры. Теперь представь что все было бы типизированным. Чтобы скомпилить код тебе бы пришлось скачивать с сайта микрософта какие-то стабы интерфейсов относительно которых ты бы компилировал код. Я тебе гарантирую, что интерфейсы различались бы у IE, firefox и chrome. Это были бы разные платформы как IOS, Android и Windows Phone. Заместо этого мы имеем богатый набор стандартов который поддерживается 3 движками браузеров. Тут я смотрел как наше приложение, которое мы таргетируем только под WebKit работает в IE11. Априори я думал что ничего не будет работать. Но я не смог найти ни одного бага специфичного для IE11, при том что мы используем современные API.
Теперь так получается что для бизнес-приложений браузер удобнее чем фреймворки на дотнете.
Основное - сборка зависимостей+кода в что-то исполняемой, запуск тестов, деплой, итд.
npm, bundler, composer занимаюся только скачкой, а для сборки отдельные программы. Это соответствует принипам unix way. В мавене все перемешано, потому что java-программисты любят не минималистичные элегатные программы, а огромные непонятные комбайны.
не понял, как описание интерфейсов на формальном языке усложнит выработку стандартов? Имхо, ровно наоборот в стандарте прописываются интерфейсы, и все им следуют со своими расширениями.
Только хотел завести такую тему. На чем сейчас пишется кровавый интерпрайз? Т.е. ты серьезно утверждаешь, что это JS? Мои мысли. Да, и для .Net и для Java все UI фрейворки оказались в какой-то жопе. Ими ни одна серьезная организация не хочет серьезно заниматься. С другой стороны UI это только часть. Писать из-за этого всё на JS, это тоже херово. Я склоняюсь к тому, что придется мириться с невзрачным "серым" UI-е, но зато код, описывающий функционал будет в нормальном состоянии, в котором его можно поддерживать и развивать. JS на такое не способен.
Теперь так получается что для бизнес-приложений браузер удобнее чем фреймворки на дотнете.
Только хотел завести такую тему. На чем сейчас пишется кровавый интерпрайз? Т.е. ты серьезно утверждаешь, что это JS? Мои мысли. Да, и для .Net и для Java все UI фрейворки оказались в какой-то жопе. Ими ни одна серьезная организация не хочет серьезно заниматься. С другой стороны UI это только часть. Писать из-за этого всё на JS, это тоже херово. Я склоняюсь к тому, что придется мириться с невзрачным "серым" UI-е, но зато код, описывающий функционал будет в нормальном состоянии, в котором его можно поддерживать и развивать. JS на такое не способен.
не понял, как описание интерфейсов на формальном языке усложнит выработку стандартов? Имхо, ровно наоборот в стандарте прописываются интерфейсы, и все им следуют со своими расширениями.Рассмотри в качестве примера SOAP. SOAP сервер на дотнете может не работать с SOAP клиентом на джаве. Это серьезная проблема. На джсоне все со всем интегрируется без проблем.
Интерпретируемым языкам несколько проще - им компилировать не надо.
Про юникс вей и прочие наезды - это ты, конечно, клево придумал, но тот же комбайн мавена тебе никто в стиле "юниксвея" использовать не мешает. Нужно только скачать депенденси - да пожалуйста.
Про юникс вей и прочие наезды - это ты, конечно, клево придумал, но тот же комбайн мавена тебе никто в стиле "юниксвея" использовать не мешает. Нужно только скачать депенденси - да пожалуйста.
Мы с тобой уже бились лбом в эту стенку, и снова начинать мне не хочется.
Да, чем качественнее автоматизировано тестирование, тем проще производить изменения в системе.
Да, чем качественнее автоматизировано тестирование, тем проще производить изменения в системе.
> Это серьезная проблема.
Существующая только у тебя.
> На джсоне все со всем интегрируется без проблем.
Только для каждого клиента приходится руками писать сериализацию/десериализацию и валидацию, и просос по перформансу, особенно в десериализации.
Существующая только у тебя.
> На джсоне все со всем интегрируется без проблем.
Только для каждого клиента приходится руками писать сериализацию/десериализацию и валидацию, и просос по перформансу, особенно в десериализации.
Да, чем качественнее автоматизировано тестирование, тем проще производить изменения в системе.Да, компилятор довольно качественно тестирует код. Есть четкий набор правил, и компилятор проверяет их соблюдение. И всем участникам эти правила известны. А ты что предлагаешь в качестве меры качества тестирования?
У нас в команде был случай. Прилежный чувак написал тесты. Его перекинули на другой проект. Пришли изменения от заказчика. Ведущий программист на проекте реализовал эти изменения за два часа. Потом два дня правил тесты. Тесты не обнаружили ни одной ошибки. Это качественные тесты?
Рассмотри в качестве примера SOAP. SOAP сервер на дотнете может не работать с SOAP клиентом на джаве. Это серьезная проблема.К чему этот XML-ый кал?
просос по перформансу, особенно в десериализации.это почему?
К чему этот XML-ый кал?К тому что таким калом заканчиваются все попытки типизировать гетерогенные системы.
типизировать гетерогенные системы.что значит типизировать гетерогенные системы? Например, пусть .Net общается с Java по json-у. Как ты написал выше, это работает. Это типизировано или нет? На обоих концах работает типизированный код, т.е. вполне можно говорить, что система типизирована целиком. А какие там байты по сети пересылаются, кого это волнует?
> Тесты не обнаружили ни одной ошибки. Это качественные тесты?
Главная цель тестов, на мой взгляд, есть сокращение суммарного времени разработки.
Если вышеописанная ситуация повторяется из релиза в релиз, то это, очевидно, плохие тесты.
Главная цель тестов, на мой взгляд, есть сокращение суммарного времени разработки.
Если вышеописанная ситуация повторяется из релиза в релиз, то это, очевидно, плохие тесты.
Потому что у тебя сначала идет синтаксический разбор, потом по имени поля ищется место куда сложить значение, и только потом идет десериализация значения из строки (дабла например, ага).
Все это вместо того, чтобы просто прочитать следующие 8 байт и сложить их в заранее известный оффсет памяти, как делает, например, протобуф.
Все это вместо того, чтобы просто прочитать следующие 8 байт и сложить их в заранее известный оффсет памяти, как делает, например, протобуф.
что значит типизировать гетерогенные системы? Например, пусть .Net общается с Java по json-у. Как ты написал выше, это работает. Это типизировано или нет? На обоих концах работает типизированный код, т.е. вполне можно говорить, что система типизирована целиком. А какие там байты по сети пересылаются, кого это волнует?В случае с соапом можно имея код на джаве и дотнете, а также компиляторы этих языков и утилиты .net2wsdl и wsdl2java гарантировать что типы на принимающей и отдающей стороне сходятся. В случае с джсоном это не так.
потом по имени поля ищется место куда сложить значениевсего лишь обращение к hash table
В случае с соапом можно имея код на джаве и дотнете, а также компиляторы этих языков и утилиты .net2wsdl и wsdl2java гарантировать что типы на принимающей и отдающей стороне сходятся. В случае с джсоном это не так.а имея утилиты net2java или java2net?
Всего лишь там, всего лишь здесь, а в итоге скапливается разница раза в два.
У нас в команде был случай. Прилежный чувак написал тесты. Его перекинули на другой проект. Пришли изменения от заказчика. Ведущий программист на проекте реализовал эти изменения за два часа. Потом два дня правил тесты. Тесты не обнаружили ни одной ошибки. Это качественные тесты?это значит, что на проекте не в первый раз реализовываются изменения за 2 часа и в целом проект скорей всего нетестируемое гавно.
Если тесты нужно переделывать два дня, то значит у вас проблемы с модульностью приложения и тесты вместо простых тестирующих один модуль тестируют сразу связку 10-ти модулей. Это значит, что если бы их не было, то очередным изменением за 2 часа оный ведущий погромист сломал бы слабую зависимость с 9-м модулем и заметили бы вы это через 3 релиза.
это значит, что на проекте не в первый раз реализовываются изменения за 2 часа и в целом проект скорей всего нетестируемое гавно.не, это был новый проект. Первый программист работ в начале проекта.
и заметили бы вы это через 3 релиза.
ты так пишешь, как будто тесты способны показать отсутствие ошибок
Главная цель тестов, на мой взгляд, есть сокращение суммарного времени разработки.Т.е. тесты тесно связаны с умением программиста вносить изменения. Кому-то для этого нужны один набор тестов, кому-то другой.
Если вышеописанная ситуация повторяется из релиза в релиз, то это, очевидно, плохие тесты.
Тесты набрали волну в начале 2000-ых, это Фаулер и компания. А это любители Смолтолка, Руби и т.п. Понятно, что на динамике не на что опереться, чтобы вносить изменения с приемлемым количеством ошибок. Вот и пошла волна по написанию тестов. Кстати, Java хоть и статически типизирована, но настолько убога, что там программирование превратили в XML, а там тоже с типами убого. Т.е. на тесты молятся там, где нету нормальной системы типов.
на тесты молятся там, где нету нормальной системы типов.На тесты молятся там, где, чтобы сделать небольшое изменение, не проводят в голове непонятно как верифицируемые доказательства корректности длиной в несколько страниц а4, а просто идут и делают изменение, быстро фиксят отвалившиеся тесты, и деплоят в прод.
Твои попытки свести разговор опять к "убогости джавы", "принципиальному различию языков" и "уникальности системы типизации c#" я не понимаю, потому что не понимаю, какие такие уникальные особенности сишарпа тебе позволяют прогать так, что QA не нужен.
Не, ты не понял. Твои выводы совершенно не правильны, они никак не следуют из того что пишу я.
Тесты это всего лишь один из инструментов. Вы молитесь на тесты, поскольку это единственное, что у вас есть для внесения изменений с приемлемым качеством в приемлемые сроки. У других, есть и другие средства для этого. Да, и что у вас приемлемое качество и сроки?
Предлагаю соревнование. Ты придумываешь задачу. Пишем решение. Через некоторое время ты выкладываешь change request к этой задаче. В итоге ты должен продемонстрировать необходимость тестов. Я по возможности буду предлагать варианты, как вносить изменения без опоры на авто тесты.
Тесты это всего лишь один из инструментов. Вы молитесь на тесты, поскольку это единственное, что у вас есть для внесения изменений с приемлемым качеством в приемлемые сроки. У других, есть и другие средства для этого. Да, и что у вас приемлемое качество и сроки?
Предлагаю соревнование. Ты придумываешь задачу. Пишем решение. Через некоторое время ты выкладываешь change request к этой задаче. В итоге ты должен продемонстрировать необходимость тестов. Я по возможности буду предлагать варианты, как вносить изменения без опоры на авто тесты.
Мы устраивали уже один раз это, помнишь, с wordwrap'ом?
Проблема в том, что ты придерживаешься идеи, что ты у себя в голове можешь провести какие-то рассуждения, которые тебя убедят, что изменение ничего не ломает, и этого достаточно.
А я придерживаюсь идеи, что этого недостаточно. Подобные рассуждения у себя в голове проводит каждый программист делая изменения, ибо ясен пень ему не хочется ломать функционал и тратить время на лишний дебаг/фикс тестов/итд. Но так как проверить справедливость этих рассуждений никто не может, то зачастую в этих рассуждениях совершаются ошибки.
Или вот, недавний пример. Пишу внутреннюю штуку. Она делает запросы к внутренним же сайтам, процессит, делает снова какие-то запросы, итд.
Запросы делаются блокирующие, подряд их все делать очень долго, зато там хорошо параллелится. Я завернул все запросы в Callable таски, и гуавой поклеил/потрансформил получившиеся ListenableFuture так, что в итоге получился один Future выдающий нужный мне результат.
То есть мое изменение затрагивало добавление конкаррент пекеджа джавы и добавление гуавы.
Как мне гарантировать, что я это все заюзал правильно? Прочитать сорс код java.util.concurrent и guava и убедиться в правильности моих предположений? Это было бы, конечно, несомненно, оч полезно для меня, но завершу я этот подвиг только за несколько недель, может быть.
При наличии тестов, понятно, я вообще не думаю.
Да, ты говорил где-то правильную мысль, своими словами правда, что тесты дают возможность не думать, и это плохо. Да, дают. И я согласен, что это плохо.
Так же как и дебаггер дает возможность не думать. Справедливо? Да, справедливо. Буду ли лично я отказываться от дебаггера? Нет, не буду. Дебаггер имеет свои преимущества - быстренько можно посмотреть что не так без вставки/удаления нудных printf. А часами в дебаггере у меня и так нету привычки сидеть, и отказ от него мне ничего не даст.
Так же и отказ от тестов не улучшит мой код и не даст мне увеличения производительности или еще чего.
Проблема в том, что ты придерживаешься идеи, что ты у себя в голове можешь провести какие-то рассуждения, которые тебя убедят, что изменение ничего не ломает, и этого достаточно.
А я придерживаюсь идеи, что этого недостаточно. Подобные рассуждения у себя в голове проводит каждый программист делая изменения, ибо ясен пень ему не хочется ломать функционал и тратить время на лишний дебаг/фикс тестов/итд. Но так как проверить справедливость этих рассуждений никто не может, то зачастую в этих рассуждениях совершаются ошибки.
Или вот, недавний пример. Пишу внутреннюю штуку. Она делает запросы к внутренним же сайтам, процессит, делает снова какие-то запросы, итд.
Запросы делаются блокирующие, подряд их все делать очень долго, зато там хорошо параллелится. Я завернул все запросы в Callable таски, и гуавой поклеил/потрансформил получившиеся ListenableFuture так, что в итоге получился один Future выдающий нужный мне результат.
То есть мое изменение затрагивало добавление конкаррент пекеджа джавы и добавление гуавы.
Как мне гарантировать, что я это все заюзал правильно? Прочитать сорс код java.util.concurrent и guava и убедиться в правильности моих предположений? Это было бы, конечно, несомненно, оч полезно для меня, но завершу я этот подвиг только за несколько недель, может быть.
При наличии тестов, понятно, я вообще не думаю.
Да, ты говорил где-то правильную мысль, своими словами правда, что тесты дают возможность не думать, и это плохо. Да, дают. И я согласен, что это плохо.
Так же как и дебаггер дает возможность не думать. Справедливо? Да, справедливо. Буду ли лично я отказываться от дебаггера? Нет, не буду. Дебаггер имеет свои преимущества - быстренько можно посмотреть что не так без вставки/удаления нудных printf. А часами в дебаггере у меня и так нету привычки сидеть, и отказ от него мне ничего не даст.
Так же и отказ от тестов не улучшит мой код и не даст мне увеличения производительности или еще чего.
Дебаггер имеет свои преимущества - быстренько можно посмотреть что не так без вставки/удаления нудных printf.Я когда программировал на джаве, выводил в лог объекты в виде джсона с помощью либы jackson. На мой взгляд в сто раз удобнее дебаггера, так как можно например на каждой итерации цикла вывести какое-то значение и потом глядя в лог сравнивать эти значения друг с другом.
Но это хорошо работало только с хорошим кодом, в котором были нормальные структуры данных. Если было намешано ООП то jackson фейлил. Циклические ссылки он вроде вообще не обрабатывал.
Я кстати удивлен, что до сих пор никто не заимплементил для джавы аналог console.log браузера. Лучшая вещь которую я видел для отладки.
Как бы я реализовал: я сделал бы либу с одной функцией - вывести в лог. Функция просто добавляет объект в список. Также либа встраивает в программу на джаве http и вебсокет сервер. К этому серверу можно приконнектиться браузером и просмотреть список выведенных в лог объектов. При этом из любого объекта можно ходить по ссылкам на любую глубину (для этого нужны вебсокеты).
Либа только для дебага, в прод билд она не попадает.
Конечно такая штука объективно вредна, потому что для отладки надо писать нормальный логгинг который можно включать на проде. Иначе получается, что при разработке использовали дебаггер, и в результате на прод попал код с нулевыми возможностями интроспекции.
Удобнее, если ты заранее знаешь, что тебе нужно.
А иначе это превращается в постоянные добавления/перезапуски.
Дебаг этим тоже страдает, но все-таки он существенно уменьшает кол-во необходимых телодвижений.
А либа - непонятно что тебе надо от нее пока кроме записи в файл. Логгинг фреймворк вот не подойдет?
Я таким, как ты, занимался только когда мне на предпродакшене надо было конкаррент ишью отдебажить, до которого пинг дикий, и ремоут дебаг не але.
Правда, я взял kryo вместо джексона, который в бинарный формат сериализует, а его аутпут в base64, и в лог. Сработало на ура.
А иначе это превращается в постоянные добавления/перезапуски.
Дебаг этим тоже страдает, но все-таки он существенно уменьшает кол-во необходимых телодвижений.
А либа - непонятно что тебе надо от нее пока кроме записи в файл. Логгинг фреймворк вот не подойдет?
Я таким, как ты, занимался только когда мне на предпродакшене надо было конкаррент ишью отдебажить, до которого пинг дикий, и ремоут дебаг не але.
Правда, я взял kryo вместо джексона, который в бинарный формат сериализует, а его аутпут в base64, и в лог. Сработало на ура.
А либа - непонятно что тебе надо от нее пока кроме записи в файл. Логгинг фреймворк вот не подойдет?Я наверное плохо объяснил. Моя идея - приделать веб-интерфейс для инспекции живых объектов внутри JVM. Чтобы понять о чем я говорю, нажми прямо сейчас F12, окрой вкладочку Console и набери там console.log(window);
А иначе это превращается в постоянные добавления/перезапуски.JPDA позволяет менять тела методов без перезапуска, не говоря уже про jrebel.
На самом деле сейчас понял что идея тупая. Все что нужно уже есть в протоколе jpda. Проблема только в том что в IDE нет удобного UI.
Плюс console.log в браузере каким-то образом умеет выводить объект в том виде как он был на момент вызова console.log. В джаве наверное это нельзя реализовать. Иммутабельность рулит в общем
Плюс console.log в браузере каким-то образом умеет выводить объект в том виде как он был на момент вызова console.log. В джаве наверное это нельзя реализовать. Иммутабельность рулит в общем
Если у тебя страничка, в которой ты нажал f5, и твой воркфлоу выполнился заново за 100мс - тогда да.
А если у тебя приложенька, которая постоянно что-то воротит там у себя, или твой воркфлоу занимает секунды-минуты, то дебаг быстрее.
А если у тебя приложенька, которая постоянно что-то воротит там у себя, или твой воркфлоу занимает секунды-минуты, то дебаг быстрее.
На самом деле сейчас понял что идея тупая. Все что нужно уже есть в протоколе jpda.=) Например?
Я наверное плохо объяснил. Моя идея - приделать веб-интерфейс для инспекции живых объектов внутри JVM. Чтобы понять о чем я говорю, нажми прямо сейчас F12, окрой вкладочку Console и набери там console.log(window);Ну в общем да, такое впечатление, что ты просто дебаг хочешь переизобрести...
=) Например?юный подаван понял, что в дебаггере есть все что нужно, чтобы наконец-то отказаться от дебаггера.
Ну в общем да, такое впечатление, что ты просто дебаг хочешь переизобрести...В дебаггере когда переменная выходит из скоупа ты уже не можешь посмотреть ее значение. Лог дает возможность посмотреть историю выполнения программы перемещаясь по ней вперед и назад. Логгинговые сообщения - это инструментирование программы которое является инвестицией в ее будущее. Нажимание кнопок в дебаггере, создание брейкпоинтов, условных брейкпоинтов, выражений для вотча никуда не сохраняется.
юный подаван понял, что в дебаггере есть все что нужно, чтобы наконец-то отказаться от дебаггера.Я дебаггер за последние два года ни разу не запускал.
Я дебаггер за последние два года ни разу не запускал.
т.е. твоё
нажми прямо сейчас F12, окрой вкладочку Consoleэто не дебаггер, а какая-то магическая хрень?
В дебаггере когда переменная выходит из скоупа ты уже не можешь посмотреть ее значение.watch-окно показывает последнее значение после выхода из блока, ровно также как и лог.
ps
вообще, логгирование(трассировка) и debug они о разном. debug позволяет понять, что происходит в конкретный момент в конкретном месте программы, а трассировка нужны для того, чтобы увидеть как ситуация развивается в целом.
это не дебаггер, а какая-то магическая хрень?Это REPL с некоторыми дополнительными возможностями
watch-окно показывает последнее значение после выхода из блока, ровно также как и лог.Я немного неточно сформулировал. Например у тебя на каждой итерации цикла создается структура. С помощью дебага ты не можешь посмотреть и сравнить глазами структуры для разных итераций.
Я немного неточно сформулировал. Например у тебя на каждой итерации цикла создается структура. С помощью дебага ты не можешь посмотреть и сравнить глазами структуры для разных итераций.можешь конечно, так что пытайся сформулировать дальше.
Плюс console.log в браузере каким-то образом умеет выводить объект в том виде как он был на момент вызова console.log. В джаве наверное это нельзя реализовать. Иммутабельность рулит в общемЯ тут ошибся. console.log делает shallow copy. Почему-то мне раньше казалось что он умеет делать снэпшот любого объекта на любую глубину, и это требует жесткой поддержки от джаваскриптового рантайма.
можешь конечно, так что пытайся сформулировать дальше.Я не знал об этом. Расскажи, какой дебаггер это поддерживает?
Я не знал об этом. Расскажи, какой дебаггер это поддерживает?любой, позволяющий выполнять выражения, для джавы точно умеют IDEA и Eclipse.
Я немного неточно сформулировал. Например у тебя на каждой итерации цикла создается структура. С помощью дебага ты не можешь посмотреть и сравнить глазами структуры для разных итераций.я не знаю, как там у вас в джаве, но в c++ всегда можно память посмотреть и увидеть эти самые структуры глазами, плюс если сильно хочется, то в VS точно можно по нужному адресу структуру визуально посмотреть
любой, позволяющий выполнять выражения, для джавы точно умеют IDEA и Eclipse.Ты не мог бы подробнее объяснить? Как выглядит UI? Как я понимаю, должен быть какой-то список, по одному элементу на каждую итерацию.
я не знаю, как там у вас в джаве, но в c++ всегда можно память посмотреть и увидеть эти самые структуры глазами, плюс если сильно хочется, то в VS точно можно по нужному адресу структуру визуально посмотретьВопрос в том, могу ли я на десятой итерации цикла посмотреть что там было на первой итерации цикла?
Вопрос в том, могу ли я на десятой итерации цикла посмотреть что там было на первой итерации цикла?ну это зависит от того, что ты там в итерациях делаешь, тебя что интересует - стэк, куча?
вообще в общем случае можно просто дампить память (интересующий кусок) на каждой итерации и потом с дампами разбираться
по любому надо будет какую-то подготовительную работу проводить
самый удобный вариант - возможность отмотать назад, к сожалению, невозможнен
самый удобный вариант - возможность отмотать назад, к сожалению, невозможненВообще, есть Chronon.
Если ты об этом заранее позаботился - то да, можешь.
Если нет - то нет. Примерно так же, как и с логгингом.
Впрочем, у меня при дебаге основной его юзкейс - это остановка в конкретных местах и проверка, что значения переменных совпадают с теми, которые, я знаю, должны быть. Все. Смотреть назад желания, как правило, не возникает.
Единственный вариант, который я могу вспомнить, это когда ты прозевал момент когда код выкинул эксепшен, и хочется вернуться к стекфрейму, где это случилось. Но тут обычно и логгинг не спасает.
Если нет - то нет. Примерно так же, как и с логгингом.
Впрочем, у меня при дебаге основной его юзкейс - это остановка в конкретных местах и проверка, что значения переменных совпадают с теми, которые, я знаю, должны быть. Все. Смотреть назад желания, как правило, не возникает.
Единственный вариант, который я могу вспомнить, это когда ты прозевал момент когда код выкинул эксепшен, и хочется вернуться к стекфрейму, где это случилось. Но тут обычно и логгинг не спасает.
Впрочем, у меня при дебаге основной его юзкейс - это остановка в конкретных местах и проверка, что значения переменных совпадают с теми, которые, я знаю, должны быть. Все. Смотреть назад желания, как правило, не возникает.Дебагаешь обычно когда что-то пошло не так. В этом случае возникает желание искать момент "не того" бинарным поиском. То есть сначала почитать состояние переменных из середины выполнения и посмотреть там. Потом откатиться назад или продолжить искать вперёд. Всматриваться в каждый шаг - слишком занудно.
Бинарный поиск, кстати, да! Хронон все твое!
Фиг знает как оно, правда, со скалой работает. Никак, наверное...
Фиг знает как оно, правда, со скалой работает. Никак, наверное...
У скалы всё очень плохо с дебагерами. Приходится обходиться логгером. Я даже консольного не нашёл.
Дебагаешь обычно когда что-то пошло не так.Еще более важное использование дебагера это въехать в тонны чужого
Еще более важное использование дебагера это въехать в тонны чужого говнокода.Это называется reverse-engineering. Если для понимания исходников он необходим, то это уже не исходники, а байткод какой-то.
Мы устраивали уже один раз это, помнишь, с wordwrap'ом?Да, очень хорошо помню. Пример закончился моим полным вином, а TDD показал свою полную несостоятельность на примере от одного из главных проповедников TDD.
Или вот, недавний пример. Пишу внутреннюю штуку. Она делает запросы к внутренним же сайтам, процессит, делает снова какие-то запросы, итд.
Запросы делаются блокирующие, подряд их все делать очень долго, зато там хорошо параллелится. Я завернул все запросы в Callable таски, и гуавой поклеил/потрансформил получившиеся ListenableFuture так, что в итоге получился один Future выдающий нужный мне результат.
То есть мое изменение затрагивало добавление конкаррент пекеджа джавы и добавление гуавы.
Как мне гарантировать, что я это все заюзал правильно? Прочитать сорс код java.util.concurrent и guava и убедиться в правильности моих предположений? Это было бы, конечно, несомненно, оч полезно для меня, но завершу я этот подвиг только за несколько недель, может быть.
При наличии тестов, понятно, я вообще не думаю.
Пример пока совершенно бесполезный в стиле: у меня был такой-то кейс, без тестов ты бы его не решил. Это стиль Фаулера, у нас такие больше задачи, что пытаться излагать их даже смысла нет — верьте мне на слово. Пока нет конкретики, какие конкретные тесты написаны, почему именно это множество тестов было написано, почему не большее множество или не меньшее множество было написан? Без этих деталей твоего примерно считай что нет.
Проблема в том, что ты придерживаешься идеи, что ты у себя в голове можешь провести какие-то рассуждения, которые тебя убедят, что изменение ничего не ломает, и этого достаточно.
А я придерживаюсь идеи, что этого недостаточно.
Проблема в том, что ты приписал мне то, чего нет. Я всегда придерживался утверждения, что люди ошибаются. Можно говорить лишь об оптимальной стратегии, которая при заданных ресурсах сводит ошибки к минимальному количеству. Соответственно, если говорим о тестах, то первый вопрос. Какие тесты должны быть написаны, а какие нет?
Оставить комментарий
luna89
Есть два основных способа добавлять зависимости в проект - комитить их в source control и использовать спец тулзы для рекурсивной скачки зависимостей - bundler для ruby, maven для джавы, npm для nodejs. В последнее время мне кажется, что такие тулзы - безусловное зло. Добавлять зависимости становится слишком легко - просто вставь строчку в конфиг. В результате появляются простые программы, которые зависят от сотни пакетов. Такие программы мало того что выглядят как помойка, они еще и вызывают ряд проблем.Во-первых, это проблемы с diamond зависимостями. Обычно такие тулзы предоставляют инструменты для решения проблемы с diamond зависимостями, но на практике обычно проще всего самому жестко прописать версии пакетов которые тебе нужны.
Во-вторых, разработчики перестают понимать, что каждая лишняя библиотека увеличивает технический долг проекта. Крайний пример - это разработка на ruby on rails в стиле обновили гем, отвалился другой гем, обновили тот гем, отвалился третий.
Вообще, я никогда не видел чтобы в проекте использовалось более чем 5-7 критических библиотек - тех, без которых сложно было бы обойтись. Если взять типичный джава/руби/нодежс проект, то сотни пакетов которые они требуют - это обычно какие-то говноплагины к веб-фреймворку, используемые в одном-двух местах, и прочий мусор, без которого проект выглядел бы лековеснее и аккуратнее.