Чет Виндовая часть с Pivoxy сложная: 1. Тунели устойчиво держит ggrandes/jentunnel: Manage SSH Tunnels made easy - пользуюсь 2 года без нареканий 2. Для винды есть проксирование приложений через Proxifier (ключи спокойно ищутся в яндекс поиске) либо ProxiFyre (OSS). Проксирую claude (через ssh) и python целиком через условно другую умную проксю _ray. На мой взгляд так удобнее.
А с ревью это очень близко к обычному процессу парного программирования.
Я думаю, что более близко к приемке решения у специалиста, который каждый раз меняется, если его строго не инструктировать. Меняется уровень результата - то джун, то мидл, то сеньёр. Меняется стиль ответа. Поэтому если проводить аналогию с парным программированием - то это парное программирование с N программистов, половину из которых можешь встретить в первые. В этом, как мой опыт показывает, сложность :)
К Сlick претензий нет, пользуюсь, удобно. Есть группы, вложенная структура команд, опции, флаги, аргументы и т.п. + расширения вида click_log и указанного ниже Trogon и м.б. что еще.
Коллега написал про ООП, забыв про ООА и ООD. Также коллега ничего не сказал о DDD. OO подход в разработке (работе с требованиями, проектировании, программировании) - это активная история 90-х и 2000-х. Я в этом время стартовал свою проф. деятельность. В основе лежит восприятие человеком внешнего мира. ОО базировалось на теории типов, теории категорий, теории множеств и в целом дополняло имеющуюся на тот момент реляционную теорию с теми же корнями. А использование Xerox объектов для организации кода - лишь проявление общего подхода применительно к UI слою и немного сомнительно что Xerox был первым в ООП, учитывая наличие реляционной теории до из 70-х. Последняя с основой в теории множеств, повторюсь, как и ОО.
Ключевое в ОО подходе - это восприятие мира человеком и коммуникация человеком информацией о мире. Было декларировано, что восприятие объектно (мы воспринимаем объекты), и коммуницируем мы информацией об объектах (говоря о собаке соседа) и абстрактно об их классах (говоря о собаках в целом). А так как машина предназначена для человека, то отражения (подчеркну) отражения объектов реального мира в структуру программ (мы называем это моделью предметной области) - хороший способ их [программ] организации (о чем собственно и пишут в комментариях).
А далее выяснилось, что много предметных областей, которые существуют только в рамках компьютерных вычислений. Например - окошки, формочки и т.п. Но они то же perceivable (воспринимаемы как объекты) и хорошие кандидаты на классы.
NB: Статья чуток поверхностная и тема ОО не раскрыта даже на 10%. Scrum нет нужды оценивать, так опять же нужно было углубиться в инженерный процесс как основу и его приложения в различных контекстах (это не простая тема). Scrum - это упрощение реального процесса, организационный framework, усреднение индивидов до team collaboration (недостатков), с заявленной потенциальной пользой от возникающей синергии и накатки одного и того же процесса (выгоды). Но тут пусть другие. Не люблю Scrum.
Чет Виндовая часть с Pivoxy сложная:
1. Тунели устойчиво держит ggrandes/jentunnel: Manage SSH Tunnels made easy - пользуюсь 2 года без нареканий
2. Для винды есть проксирование приложений через Proxifier (ключи спокойно ищутся в яндекс поиске) либо ProxiFyre (OSS). Проксирую claude (через ssh) и python целиком через условно другую умную проксю _ray. На мой взгляд так удобнее.
Я думаю, что более близко к приемке решения у специалиста, который каждый раз меняется, если его строго не инструктировать. Меняется уровень результата - то джун, то мидл, то сеньёр. Меняется стиль ответа. Поэтому если проводить аналогию с парным программированием - то это парное программирование с N программистов, половину из которых можешь встретить в первые. В этом, как мой опыт показывает, сложность :)
Тут спор с коллегой не имеет смысла :). Поддержу Вашу точку зрения.
К Сlick претензий нет, пользуюсь, удобно. Есть группы, вложенная структура команд, опции, флаги, аргументы и т.п. + расширения вида click_log и указанного ниже Trogon и м.б. что еще.
Коллега написал про ООП, забыв про ООА и ООD. Также коллега ничего не сказал о DDD. OO подход в разработке (работе с требованиями, проектировании, программировании) - это активная история 90-х и 2000-х. Я в этом время стартовал свою проф. деятельность. В основе лежит восприятие человеком внешнего мира. ОО базировалось на теории типов, теории категорий, теории множеств и в целом дополняло имеющуюся на тот момент реляционную теорию с теми же корнями. А использование Xerox объектов для организации кода - лишь проявление общего подхода применительно к UI слою и немного сомнительно что Xerox был первым в ООП, учитывая наличие реляционной теории до из 70-х. Последняя с основой в теории множеств, повторюсь, как и ОО.
Ключевое в ОО подходе - это восприятие мира человеком и коммуникация человеком информацией о мире. Было декларировано, что восприятие объектно (мы воспринимаем объекты), и коммуницируем мы информацией об объектах (говоря о собаке соседа) и абстрактно об их классах (говоря о собаках в целом). А так как машина предназначена для человека, то отражения (подчеркну) отражения объектов реального мира в структуру программ (мы называем это моделью предметной области) - хороший способ их [программ] организации (о чем собственно и пишут в комментариях).
А далее выяснилось, что много предметных областей, которые существуют только в рамках компьютерных вычислений. Например - окошки, формочки и т.п. Но они то же perceivable (воспринимаемы как объекты) и хорошие кандидаты на классы.
NB: Статья чуток поверхностная и тема ОО не раскрыта даже на 10%. Scrum нет нужды оценивать, так опять же нужно было углубиться в инженерный процесс как основу и его приложения в различных контекстах (это не простая тема). Scrum - это упрощение реального процесса, организационный framework, усреднение индивидов до team collaboration (недостатков), с заявленной потенциальной пользой от возникающей синергии и накатки одного и того же процесса (выгоды). Но тут пусть другие. Не люблю Scrum.