|
|
10.09.16
|
|
|
Re: Инструменты для создания OXP |
|
|
Продолжим разговор об инструментах. VCS - системы контроля версий (Version Control System)Хотел найти нормальную статью с описанием "зачем это нужно", но ничего толкового не нашел. Если кратко, то VCS упорядочивает тот бардак, что образуется на диске при разработке: куча файлов / папок с копиями или прошлыми версиями. В файлах больше закоментаренного кода (на всякий случай), чем реально используемого кода. Совместная работа крайне усложнена и происходит на уровне "переслал архив, глянь". Что и откуда взялось, зачем правилось и т.д. знает только тот, кто это сделал (и если прошло не так много времени). Если чуть подробнее, то основные задачи VCS: - История изменений. Каждое изменение явно фиксируется в истории с явным перечнем изменений и комментарием разработчика.
- Контроль версий. Все версии в одном месте, по истории всегда видно какие именно изменения были включены в версию.
- Совместная работа. VCS позволяет организовать совместную работу над одним кодом. Все имеют доступ к единой истории изменений и всегда имеют актуальную версию приложения.
Дополнительно можно почитать википедию или воспользоваться помощью высшего разума. Могу порекомендовать следующее VCS:- Mercurial, он же Hg. Современная продвинутая децентрализованная VCS. Основной особенностью могу назвать простоту, дружественность к новичкам и наличие очень удобного кросс-платформенного GUI к ней - TortoiseHg. Лично я предпочитаю эту VCS за GUI и невозможность (или вернее крайнюю сложность) "выстрелить к себе в ногу".
- Git. Современная продвинутая децентрализованная VCS. Можно смело назвать современным стандартом для систем управления версиями. Лично я ее не очень жалую из-за сложности, необходимости использовать коммандной строки (GUI есть, но не столь удобные), недружественности к новичкам (очень просто выстрелить себе в ногу).
В целом, Hg / git обладают равными возможностями и выбор между ними крайне холиварен. Но лично я предпочитаю Hg именно из-за большей дружественности к пользователям. Хостинг проектовСоздать проект и положить его в VCS мало. Необходимо еще и хостить где-нибудь этот проект, чтобы была возможность обмениваться кодом проекта, получать доступ к коду из любого места и не зависеть от жизни винта компьютера. - Bitbucket - популярное место хостинга проектов. Поддерживает Hg / git. На бесплатном аккаунте можно создавать приватные репозитории (до 5 пользователей).
- GitHub - фактически стандарт для хостинга проектов с открытым исходным кодом. Поддерживает только git. На бесплатном тарифе можно создавать исключительно общедоступные репозитории (приватные - только на платных тарифах).
Помимо хостинга репозитория, Bitbucket и GitHub предоставляют место для ведения документации (wiki проекта) и менеджер задач (Issue tracker). Также предоставляют возможность публикации релизов. Лично я предпочитаю Bitbucket из-за поддержки Hg и приватных репозиториев на бесплатном тарифе.
Продолжим разговор об инструментах.
[size=150]VCS - системы контроля версий (Version Control System)[/size] Хотел найти нормальную статью с описанием "зачем это нужно", но ничего толкового не нашел.
Если кратко, то VCS упорядочивает тот бардак, что образуется на диске при разработке: куча файлов / папок с копиями или прошлыми версиями. В файлах больше закоментаренного кода (на всякий случай), чем реально используемого кода. Совместная работа крайне усложнена и происходит на уровне "переслал архив, глянь". Что и откуда взялось, зачем правилось и т.д. знает только тот, кто это сделал (и если прошло не так много времени).
Если чуть подробнее, то основные задачи VCS: [list] [*]История изменений. Каждое изменение явно фиксируется в истории с явным перечнем изменений и комментарием разработчика. [*]Контроль версий. Все версии в одном месте, по истории всегда видно какие именно изменения были включены в версию. [*]Совместная работа. VCS позволяет организовать совместную работу над одним кодом. Все имеют доступ к единой истории изменений и всегда имеют актуальную версию приложения. [/list]
Дополнительно можно почитать [url=https://ru.wikipedia.org/wiki/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D1%8F%D0%BC%D0%B8]википедию[/url] или воспользоваться [url=https://www.google.ru/search?q=%D0%B7%D0%B0%D1%87%D0%B5%D0%BC+%D0%BD%D1%83%D0%B6%D0%BD%D1%8B+%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B+%D0%BA%D0%BE%D0%BD%D1%82%D1%80%D0%BE%D0%BB%D1%8F+%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D0%B9]помощью высшего разума[/url].
[u][b]Могу порекомендовать следующее VCS:[/b][/u] [list=1] [*][b]Mercurial, он же Hg[/b]. Современная продвинутая децентрализованная VCS. Основной особенностью могу назвать простоту, дружественность к новичкам и наличие очень удобного кросс-платформенного GUI к ней - [url=http://tortoisehg.bitbucket.org/]TortoiseHg[/url]. Лично я предпочитаю эту VCS за GUI и невозможность (или вернее крайнюю сложность) "выстрелить к себе в ногу". [*][b]Git[/b]. Современная продвинутая децентрализованная VCS. Можно смело назвать современным стандартом для систем управления версиями. Лично я ее не очень жалую из-за сложности, необходимости использовать коммандной строки (GUI есть, но не столь удобные), недружественности к новичкам (очень просто выстрелить себе в ногу).[/list]
В целом, Hg / git обладают равными возможностями и выбор между ними крайне холиварен. Но лично я предпочитаю Hg именно из-за большей дружественности к пользователям.
[size=150]Хостинг проектов[/size] Создать проект и положить его в VCS мало. Необходимо еще и хостить где-нибудь этот проект, чтобы была возможность обмениваться кодом проекта, получать доступ к коду из любого места и не зависеть от жизни винта компьютера. [list=1] [*][url=https://bitbucket.org/]Bitbucket[/url] - популярное место хостинга проектов. Поддерживает Hg / git. На бесплатном аккаунте можно создавать приватные репозитории (до 5 пользователей). [*][url=https://github.com/]GitHub[/url] - фактически стандарт для хостинга проектов с открытым исходным кодом. Поддерживает только git. На бесплатном тарифе можно создавать исключительно общедоступные репозитории (приватные - только на платных тарифах).[/list]
Помимо хостинга репозитория, Bitbucket и GitHub предоставляют место для ведения документации (wiki проекта) и менеджер задач (Issue tracker). Также предоставляют возможность публикации релизов.
Лично я предпочитаю Bitbucket из-за поддержки Hg и приватных репозиториев на бесплатном тарифе.
|
|
|
|
|
22.08.16
|
|
|
Инструменты для создания OXP |
|
|
Предлагаю обсудить инструментарий, используемый для создания OXP.По большому счету, все что надо для создания OXP - текстовый редактор. Если в OXP есть скрипты, то лучше взять редактор с подсветкой синтаксиса JavaScript (мои дополнения исключительно из JavaScript и состоят). Я предпочитаю использовать не просто продвинутый редактор, а полноценные IDE (IDE - интегрированная среда разработки). Почему IDE? JavaScript - это скриптовый язык, поэтому все любая ошибка может быть обнаружена только после запуска приложения. Любая опечатка может привести к падению, или что еще хуже, к некорректному поведению приложения (падение хотя бы видно сразу). IDE - не только продвинутый текстовый редактор, но и полноценная экосистема вокруг него: - Полноценная отладка (для Oolite неприменима). Программирование это прежде всего не написание кода, а его переписывание с целью улучшения функциональности или исправления ошибок. А для этого необходимо понимать, что в коде происходит. Отладка - лучший способ понять код. К сожалению, Oolite позволяет только выводить сообщения в лог, что не просто "прошлый век", а "прошлое тысячелетие" в отладке.
- Подсказки по используемым функциям и именам переменных. Минимизирует число опечаток.
- Базовая валидация кода. Позволяет находить и показывать типовые ошибки непосредственно в редакторе кода (т.е. до запуска приложения).
- Форматирование кода (не во всех IDE, но в нижеперечисленных есть). Любой код - это прежде всего текст. И чем лучше структурирован текст, тем лучше его читать (особенно другим людям). Форматирование кода позволяет подогнать форматирование текста под некие общепринятые правила.
Рекомендую следующие IDE:- Visual Studio Code - легковесная бесплатная IDE, доступна под основные платформы (Windows / Linux / Mac OS X). Стоит отметить то, что не требует создания отдельных файлов проекта. Любая папка может стать проектом, достаточно ее открыть в редакторе.
- Cloud 9 IDE - онлайн-IDE (есть бесплатные тарифы)! Работа из браузера на любом месте. Основной особенностью назову возможность работы из нескольких мест над одним кодом. Т.е. дома / на работе / у бабушки - всегда есть возможность прерваться и продолжить работу в другом месте. Еще стоит добавить, что это не просто IDE, а предоставляется полноценный сервер на Ubuntu, в рамках которого и работает IDE. Так что для раскрытия всех возможностей понадобятся знания командной строки. Помимо прочего, Cloud 9 дает возможность совместной работы над одним и тем же кодом.
Как я работаю над дополнением:- Создаю папку дополнения в Cloud 9 (развернут на собственном сервере).
- Пишу собственно плагин.
- Загружаю для проверки плагин локально.
- Локально открываю проект в VS Code и отлаживаю ошибки.
- Переношу исправления на Cloud 9.
- Пакую в OXZ.
- Локально проверяю работу пакета в формате OXZ.
- Выкладываю пакет дополнения.
Параллельно веду историю правок в системе управления версиями (git или Mercurial (hg)).
[u]Предлагаю обсудить инструментарий, используемый для создания OXP.[/u]
По большому счету, все что надо для создания OXP - текстовый редактор. Если в OXP есть скрипты, то лучше взять редактор с подсветкой синтаксиса JavaScript (мои дополнения исключительно из JavaScript и состоят).
Я предпочитаю использовать не просто продвинутый редактор, а полноценные IDE (IDE - интегрированная среда разработки). [u]Почему IDE?[/u] JavaScript - это скриптовый язык, поэтому все любая ошибка может быть обнаружена только после запуска приложения. Любая опечатка может привести к падению, или что еще хуже, к некорректному поведению приложения (падение хотя бы видно сразу). IDE - не только продвинутый текстовый редактор, но и полноценная экосистема вокруг него: [list][*]Полноценная отладка (для Oolite неприменима). Программирование это прежде всего не написание кода, а его переписывание с целью улучшения функциональности или исправления ошибок. А для этого необходимо понимать, что в коде происходит. Отладка - лучший способ понять код. К сожалению, Oolite позволяет только выводить сообщения в лог, что не просто "прошлый век", а "прошлое тысячелетие" в отладке.[/*] [*]Подсказки по используемым функциям и именам переменных. Минимизирует число опечаток.[/*] [*]Базовая валидация кода. Позволяет находить и показывать типовые ошибки непосредственно в редакторе кода (т.е. до запуска приложения).[/*] [*]Форматирование кода (не во всех IDE, но в нижеперечисленных есть). Любой код - это прежде всего текст. И чем лучше структурирован текст, тем лучше его читать (особенно другим людям). Форматирование кода позволяет подогнать форматирование текста под некие общепринятые правила.[/*][/list]
[b]Рекомендую следующие IDE:[/b] [list=1] [*][b][url=https://code.visualstudio.com/]Visual Studio Code[/url][/b] - легковесная бесплатная IDE, доступна под основные платформы (Windows / Linux / Mac OS X). Стоит отметить то, что не требует создания отдельных файлов проекта. Любая папка может стать проектом, достаточно ее открыть в редакторе.[/*] [*][b][url=https://c9.io/]Cloud 9 IDE[/url][/b] - онлайн-IDE (есть бесплатные тарифы)! Работа из браузера на любом месте. Основной особенностью назову возможность работы из нескольких мест над одним кодом. Т.е. дома / на работе / у бабушки - всегда есть возможность прерваться и продолжить работу в другом месте. Еще стоит добавить, что это не просто IDE, а предоставляется полноценный сервер на Ubuntu, в рамках которого и работает IDE. Так что для раскрытия всех возможностей понадобятся знания командной строки. Помимо прочего, Cloud 9 дает возможность совместной работы над одним и тем же кодом.[/*] [/list]
[u]Как я работаю над дополнением:[/u] [list=1] [*]Создаю папку дополнения в Cloud 9 (развернут на собственном сервере).[/*] [*]Пишу собственно плагин.[/*] [*]Загружаю для проверки плагин локально.[/*] [*]Локально открываю проект в VS Code и отлаживаю ошибки.[/*] [*]Переношу исправления на Cloud 9.[/*] [*]Пакую в OXZ.[/*] [*]Локально проверяю работу пакета в формате OXZ.[/*] [*]Выкладываю пакет дополнения.[/*] [/list] Параллельно веду историю правок в системе управления версиями (git или Mercurial (hg)).
|
|
|
|
|
|