Есть опыт разработки приложений на J2EE/Groovy/Scala. Работаю в крупнейшей аутсорсинговой компании. Мой код постоянно ревьювится разработчиками заказчика. Обзоры субъективны. Их адекватность прошу оценивать по содержанию, а не титулованности обзорщика.
Code review делаю на основании интереса к проекту, чтобы в первую очередь для себя разъяснить как оно все работает.
Все что поверх JVM, все попадает в область видимости. Дело в приоритетах. Android — бесспорно, интересный проект с открытыми исходными кодами. Рано или поздно возьмемся за него.
При составлении статей, я связываюсь с разработчиками для прояснения некоторых моментов. Можно попробовать пойти от обратного. Уважаемые разработчики Open Source проектов, свяжитесь со мной, если вы готовы поговорить о вашем проекте для queuepy.com.
К слову сказать, если у вас есть Android телефон, то вы можете переводить слово с Google Translate и экспортировать его с переводом в AnkiDroid. Я сравнительно недавно добавил туда фичу, которая фильтрует мусор из экспортируемого текста Google Translate и вставляет в карту только оригинальное слово и перевод. Уже пол года учу слова по этому принципу.
Изучение нового на практике начинается только после изучения теории. Планирую исправить пару мажорных багов, а затем добавлять новый функционал лишь с целью освещения интересных технологий. В первую очередь, memorized — это учебный проект для меня и других разработчиков. Хотя не могу утверждать с уверенностью, что в дальнейшем из этого ничего путного для рядого пользователя не выйдет. Спасибо за аналогию с Trello — не слышал о нем раньше.
Ради эксперимента выкатил на jelastic свой проект. Очень удручает отсутствие какой-либо возможности автодеплоя. У OpenShift, например, есть git-репозиторий, что намного упрощает процесс пересборки приложения. Вы не планируете внедрить что-нибудь подобное?
Под «призраком» я понимаю файл, который постоянно маячит в коммитах. Среди них может быть и обычный файл проекта. Т.е. в файле изменений нет, а он всё-равно отображается как измененный. Вот такие артефакты порой появляются из-за ошибочных коммитов или проблем самого svn. С ростом проекта их число только увеличивается.
Такие последствия тяжелы на проекте любой величины.
На больших проектах вероятность появления всяких svn-артефактов увеличивается. Появляются кучи призрачных файлов и директорий, которые маячат из коммита в коммит. Их то и приходится игнорировать при коммите своих изменений.
Спасибо. Это то, что нужно.
Тем не менее, программы-мониторы удобны в получении актуальной информации об изменениях. А автообновление легко отключить во время разработки. К тому же многие ветки не редактируются, а просто служат целью для мержа.
Предпочитаю работать с svn децентрализованно — из консоли, в интеграции с системой(ToroiseSVN) и из IDE. CommitMonitor дает мне возможность видеть обновления независимо от источника. Vercue — решение в себе. Не вижу особого преимущества, которое стоило бы 40 или 100 евро. Конечно, в единой точке входа в svn свои плюсы, но и проблемы там другие, а не те которые описаны в статье.
Code review делаю на основании интереса к проекту, чтобы в первую очередь для себя разъяснить как оно все работает.
На больших проектах вероятность появления всяких svn-артефактов увеличивается. Появляются кучи призрачных файлов и директорий, которые маячат из коммита в коммит. Их то и приходится игнорировать при коммите своих изменений.
Тем не менее, программы-мониторы удобны в получении актуальной информации об изменениях. А автообновление легко отключить во время разработки. К тому же многие ветки не редактируются, а просто служат целью для мержа.