Нет, aider не пробовал, уже не первый раз мне про него говорят, нужно попробовать. Еще хочу сравнить сервисы которые в основном под разработку фронта заточены - v0, bolt, lovable, replit.. Найти бы еще время на все эти развлечения)
Я очень хорошо понимаю людей, у которых шум вокруг AI ассистентов, истории про замену очередной категории специалистов и тд, вызывает раздражение. Я сам такой. Но вынужден признать, что вот эту конкретную задачу - "прототипирование простой идеи" - я бы сам выполнял гораздо дольше. И это при том что навык быстрого прототипирования у меня есть.
Когда-то весь код писался на ассемблере. Люди создавали произведения искусства (взять например WozMon от Стива Возняка - практически OS в 254 байта). Теперь практический весь машинный код генерируется компиляторами высокуровневых языков. Я могу представить себе будущее, в котором люди практически не пишут код руками. Не знаю, нравится ли мне это... Поживем - увидим.
Выкатка в прод немного отличается. Алгоритм следующий: 1. Lock master branch 2. Rebase on origin/master 3. Deploy to production 4. Track metrics 5. Merge to master 6. Unlock master
Если на 4-м шаге возникли какие-то проблемы то просто откатываем на последний мастер. Разработчик полностью отвечает за весь цикл разработки фичи и сам катит ее в прод. Каждая фича катится атомарно, то есть нет необходимости выяснять кто и что сломал в ветке где идет интеграция при подготовке релиза, так как "релизов" по сути нет. При таком флоу нормальная продуктивная команда из 5-7 человек катит в прод 2-3 раза в день.
Мы же особенности flow обсуждаем, причем тут джуны и ошибки?
Как раз с точки зрения риска и сложности gitflow проигрывает, если мы говорим о типичной backend разработке.
Зачем рисковать возникновением эмерджентных багов при интеграции фич , усложнять цикл разработки и размывать ответственность введением таких ролей как релиз-инженер и тд, когда можно быстро катить фичи атомарно?
Научить людей ребейзить - не очень сложная задача.
При чем тут конфликты? Если мы ребейзнули ветку на последний мастер, то мерж этой ветки в мастер будет fast-forward, master и feature-branch будут указателями на один и тот же коммит.
Снепшот кода который мы деплоим будет одинаковым в обоих вариантах флоу:
# flow 1
git fetch
git rebase origin/master
deploy to prod
git checkout master
git merge feature-branch
# flow 2
git fetch
git rebase origin/master
git checkout master
git merge feature-branch
deploy to prod
Понятно что в реальности есть куча нюансов, если команда большая, то возможно будет нужно настроить merge queue и тд., но думаю, общий смысл понятен.
"звучит неправильно" - так себе аргумент. Код в ветке после ребейза на мастер ничем не отличается от кода в мастере после мержа. Разница между этими подходами только в том, что сливая в мастер до выкатки мы увеличиваем вероятность получить сломанный коммит в мастере.
GitFlow имеет смысл только если нет простого механизма отката изменений из прода (читай "мобильная разработка"). В остальных случаях GitHub Flow проще и стабильнее. Для обеспечения стабильности, катить в прод нужно до того как слили в мастер, и сливать только после того как убедились, что ничто не сломано. Если сломано - rollback на последний мастер в общем случае.
Разумно предположить, что доступ к объекту obj[key] займет O(1), но на деле это определяется многими факторами — размером объекта, частотой создания / удаления etc...
Не вижу причин не поговорить на собеседовании о производительности и ее связи с асимптотическим анализом сложности. Например из этого рассуждения я бы сделал вывод что кандидат знаком с самой идеей, нотацией и некоторыми классическими структурами данных, но не очень понимает идею амортизированной трудоемкости. В принципе, позволяет сделать какие-то выводы об уровне кандидата. Что плохого в таких вопросах?
In the present case of 2019-nCoV, virus isolates or samples from infected patients have so far not become available to the international public health community. We report here on the establishment and validation of a diagnostic workflow for 2019-nCoV screening and specific confirmation, designed in absence of available virus isolates or original patient specimens. Design and validation were enabled by the close genetic relatedness to the 2003 SARS-CoV, and aided by the use of synthetic nucleic acid technology.
Но забавно, что автор этого не заметил. Кажется, он материалы по собственным ссылкам не читал :)
Хорошая идея!
Хороший вопрос. Как по-вашему было бы правильно?
Claude Code работает локально с файлами в файловой системе.
Нет, aider не пробовал, уже не первый раз мне про него говорят, нужно попробовать. Еще хочу сравнить сервисы которые в основном под разработку фронта заточены - v0, bolt, lovable, replit.. Найти бы еще время на все эти развлечения)
Да, прожорливый. От идеи до первой "deployable" версии - $50 примерно. Еще столько же на допиливание.
Код в приватном репозитории, но я выложил в гисты примеры документации:
Concept.md
API.md
WebApp.md
Feedback.md
Задумывалось как "Unbiased Dispute Resolution Assistant" 😁
Я очень хорошо понимаю людей, у которых шум вокруг AI ассистентов, истории про замену очередной категории специалистов и тд, вызывает раздражение. Я сам такой. Но вынужден признать, что вот эту конкретную задачу - "прототипирование простой идеи" - я бы сам выполнял гораздо дольше. И это при том что навык быстрого прототипирования у меня есть.
Когда-то весь код писался на ассемблере. Люди создавали произведения искусства (взять например WozMon от Стива Возняка - практически OS в 254 байта). Теперь практический весь машинный код генерируется компиляторами высокуровневых языков. Я могу представить себе будущее, в котором люди практически не пишут код руками. Не знаю, нравится ли мне это... Поживем - увидим.
В общем и целом - https://githubflow.github.io/
Выкатка в прод немного отличается. Алгоритм следующий:
1. Lock master branch
2. Rebase on origin/master
3. Deploy to production
4. Track metrics
5. Merge to master
6. Unlock master
Если на 4-м шаге возникли какие-то проблемы то просто откатываем на последний мастер.
Разработчик полностью отвечает за весь цикл разработки фичи и сам катит ее в прод. Каждая фича катится атомарно, то есть нет необходимости выяснять кто и что сломал в ветке где идет интеграция при подготовке релиза, так как "релизов" по сути нет. При таком флоу нормальная продуктивная команда из 5-7 человек катит в прод 2-3 раза в день.
Мы же особенности flow обсуждаем, причем тут джуны и ошибки?
Как раз с точки зрения риска и сложности gitflow проигрывает, если мы говорим о типичной backend разработке.
Зачем рисковать возникновением эмерджентных багов при интеграции фич , усложнять цикл разработки и размывать ответственность введением таких ролей как релиз-инженер и тд, когда можно быстро катить фичи атомарно?
Научить людей ребейзить - не очень сложная задача.
При чем тут конфликты? Если мы ребейзнули ветку на последний мастер, то мерж этой ветки в мастер будет fast-forward, master и feature-branch будут указателями на один и тот же коммит.
Снепшот кода который мы деплоим будет одинаковым в обоих вариантах флоу:
Понятно что в реальности есть куча нюансов, если команда большая, то возможно будет нужно настроить merge queue и тд., но думаю, общий смысл понятен.
Расскажите это ребятам из google или yandex :)
"звучит неправильно" - так себе аргумент. Код в ветке после ребейза на мастер ничем не отличается от кода в мастере после мержа. Разница между этими подходами только в том, что сливая в мастер до выкатки мы увеличиваем вероятность получить сломанный коммит в мастере.
GitFlow имеет смысл только если нет простого механизма отката изменений из прода (читай "мобильная разработка"). В остальных случаях GitHub Flow проще и стабильнее. Для обеспечения стабильности, катить в прод нужно до того как слили в мастер, и сливать только после того как убедились, что ничто не сломано. Если сломано - rollback на последний мастер в общем случае.
Может, если задачи несложные.
Не вижу причин не поговорить на собеседовании о производительности и ее связи с асимптотическим анализом сложности. Например из этого рассуждения я бы сделал вывод что кандидат знаком с самой идеей, нотацией и некоторыми классическими структурами данных, но не очень понимает идею амортизированной трудоемкости. В принципе, позволяет сделать какие-то выводы об уровне кандидата. Что плохого в таких вопросах?
Спасибо, ребята. Вы делаете очень крутые инструменты!
> Стоит отметить, что цикл событий встроен в Go
Что вы имеете в виду?
Но забавно, что автор этого не заметил. Кажется, он материалы по собственным ссылкам не читал :)