По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Дистрибутив FreePBX Distro имеет встроенный скрипт, который позволяет изменить текущую (используемую) версию Asterisk. Важно, что сделать это можно буквально за минуту, и без проблем вернуться на ранее используемую версию.
При смене версии используется только одна команда, после ввода которой, мы остается следовать подсказкам меню. Команда следующая:
[root@localhost ~]# asterisk-version-switch
На следующем этапе, скрипт спросит на какую версию вы хотите переключиться:
Pick the Asterisk Version you would like to change to.
Press 1 and the Enter key for Asterisk 11
Press 2 and the Enter key for Asterisk 13
Press 3 and the Enter key for Asterisk 14 (Currently in beta)
Press 9 and the Enter key to exit and not change your Asterisk Version
Нажимаем 1 для переключения на 11 версию Asterisk
Нажимаем 2 для переключения на 13 версию Asterisk
Нажимаем 3 для переключения на 14 версию Asterisk (сейчас в Beta состоянии)
Нажимаем 9 выхода из скрипта без изменений версии
Далее начнется изменение конфигурации в соответствие с выбранной версией. По окончанию работы вы можете проверить текущую версию с помощью команды:
[root@localhost ~]# asterisk -x "core show version"
Asterisk 13.10.0 built by mockbuild @ jenkins2.schmoozecom.net on a i686 running Linux on 2016-07-27 01:24:12 UTC
Если версия осталась прежней, дайте в консоль команду:
[root@localhost ~]# fwconsole restart
По окончанию перезагружаем конфигурацию и Asterisk:
[root@localhost ~]# fwconsole reload
Уже прошло несколько лет с тех пор, как появился Kotlin, и он преуспевает. Так как Kotlin был создан в качестве замены Java, то его, как и следовало ожидать, во многом сравнивают именно с ним.
Чтобы помочь вам выбрать один из двух языков, я сравню основные аспекты каждого из них.
Вот 8 пунктов, которые я рассмотрю в этой статье:
Синтаксис
Лямбда-выражения
Обработка нулей
Классы предметной области
Глобальные переменные
Параллелизм
Функции расширения
Сообщество
Сравнение синтаксиса
Давайте сначала проведем сравнение базового синтаксиса. Я думаю, что многие из вас, кто читает эту статью, возможно, уже знают кое-что о Java и/или Kotlin, но я все же приведу пример, чтобы мы могли явно их сравнить:
Java
public class HelloClass {
public void FullName(String firstName, String lastName) {
String fullName = firstName + " " + lastName;
System.out.println("My name is : " + fullName);
}
public void Age() {
int age = 21;
System.out.println("My age is : " + age);
}
public static void main(String args[]) {
HelloClass hello = new HelloClass();
hello.FullName("John","Doe");
hello.Age();
}
}
Kotlin
class NameClass {
fun FullName(firstName: String, lastName:String) {
var fullName = "$firstName $lastName"
println("My Name is : $fullName")
}
}
fun Age() {
var age : Int
age = 21
println("My age is: $age")
}
fun main(args: Array) {
NameClass().FullName("John","Doe")
Age()
}
Код не сильно отличается, если не считать небольших различий в синтаксисе методов и классов.
Но реальное различие заключается в том, что Kotlin поддерживает вывод типов, где тип переменной не нужно объявлять. А еще там не нужны точки с запятой ( ; ).
Также можно отметить, что Kotlin не сильно придерживается принципов ООП, в отличие от Java, где все содержится внутри класса. Посмотрите хотя бы на функции Age и main в примере – они не находятся внутри класса.
Kotlin, как правило, имеет меньше строк кола, а вот Java придерживается традиционного подхода и, соответственно, является достаточно многословным.
Одно из преимуществ Kotlin перед Java – он может делать все, используя как традиционный ООП-подход, так и любой другой.
Лямбда-выражения
Если мы заговорили о Java и Kotlin, то мы, конечно же, должны поговорить об их знаменитых лямбда-выражениях. У Kotlin есть встроенная поддержка лямбда-функций (и всегда была), а вот в Java она появилась только в Java 8.
Давайте посмотрим, как они выглядят.
Java
//syntaxes
parameter -> expression
(parameter1, parameter2) -> { code }
//sample usage
ArrayList numbers = new ArrayList();
numbers.add(5);
numbers.add(9);
numbers.forEach( (n) -> { System.out.println(n); } );
Kotlin
//syntax
{ parameter1, parameter2 -> code }
//sample usage
max(strings, { a, b -> a.length < b.length })
В Java скобки не являются обязательными: если есть только один параметр, то они не нужны. Но в Kotlin скобки нужны всегда. Однако, в общем и целом, помимо синтаксиса, различий не так уж и много.
Как по мне, лямбда-функции используются только в качестве методов обратного вызова. Хоть они и имеют гораздо более широкий спектр применений, все же они не очень читабельны, в связи с чем их реже используют. Они, конечно, сократят объем вашего кода, но разобраться в нем потом будет достаточно сложно.
Это вопрос предпочтений, но мне кажется, что намного удобнее, когда скобки используются всегда, как в Kotlin, потому что так код становится более читабельным.
Обработка нулей
В объектно-ориентированном языке значения нулевого типа всегда были проблемой. Когда вы пытаетесь использовать содержимое нулевого значения, выпадает исключение нулевого указателя (NPE - Null Pointer Exception).
Поскольку NPE всегда были проблемой, то и у Java, и у Kotlin есть свой способ обработки нулевых объектов. Как они это делают, я покажу ниже.
Java
Object object = objServ.getObject();
//traditional approach of null checking
if(object!=null){
System.out.println(object.getValue());
}
//Optional was introduced in Java 8 to further help with null values
//Optional nullable will allow null object
Optional
Введение
За счет ветвления в Git разработчики могут работать сразу над несколькими функциями или изменениями, не мешая друг другу и не меняя основную кодовую базу. Поскольку ветки – это неотъемлемая часть Git, были приняты некоторые соглашения о присвоении им имен, призванные поддерживать понятность и структурированность кодовой базы.
Особенно важно придерживаться методических рекомендаций по присвоению имен, когда вы работаете над проектом совместно с другими разработчиками. Это позволит избежать путаницы и обеспечит планомерность работы каждого.
В этой статье мы расскажем о различных соглашениях о присвоении имен веткам Git и поделимся рекомендациями, как создать структурированный репозиторий.
Типы веток в Git
Ветки в Git можно разделить на два типа в зависимости от их продолжительности жизни и типа вносимых ими изменений:
Постоянные ветки
Временные ветки
Такое разделение позволяет командам эффективнее управлять своими рабочими процессами в Git. Правильно выбранные имена гарантируют, что ветки с длительным жизненным циклом будут стабильными, а временные ветки будут использоваться для конкретных сиюминутных задач и не будут наводить беспорядок в репозитории.
В следующих разделах мы подробнее описали эти типы веток.
Постоянные ветки
Постоянные ветки Git – это ветки с длительным жизненным циклом, которые являются надежным и структурированным способом организации текущей работы. Эти ветки доступны в репозитории на постоянной основе, а их имена довольно просты.
Вот некоторые постоянные ветки Git:
Основная ветка (master/main)
. Производственная ветка в репозитории Git, используемая по умолчанию, которая должна быть неизменно стабильной. Разработчики могут включать изменения в основную ветку только после рецензирования и тестирования кода. Все участники проекта обязаны поддерживать стабильность и актуальность основной ветки.
Ветка разработки (dev)
. Главная ветка разработки, которая выступает в качестве центрального узла для разработчиков, где они могут интегрировать свои новые функции, исправлять какие-то ошибки и вносить любые другие изменения. Ее основная задача – быть тем местом, где разработчики могут вносить изменения, не реализовывая их непосредственно в основной ветке. Разработчики тестируют, рецензируют и только потом включают эти изменения в основную ветку.
Ветка контроля качества (QA/test)
. Эта ветка содержит весь код, готовый к проверке качества и автоматизированному тестированию. Тестирование качества – это необходимый этап перед добавлением каких-либо изменений в производственную среду, который позволяет поддерживать стабильность кодовой базы.
Временные ветки
Временные ветки – это одноразовые ветки с непродолжительным жизненным циклом. Эти ветки служат конкретным сиюминутным целям и чаще всего потом удаляются.
Вот некоторые временные ветки Git:
Bugfix-ветка
. Эта ветка содержит код с ошибками, которые необходимо исправить как можно скорее. Это может быть отклоненный код из feature-веток, который необходимо исправить перед внедрением.
Hotfix-ветка
. Это ветка для внедрения временного решения в ошибочный код без соблюдения стандартной процедуры. Эта ветка используется только в экстренных случаях и когда необходимо быстро внести исправление. Разработчики включают hotfix-ветку непосредственно в производственную ветку, а затем уже в ветку разработки.
Feature-ветка
. Эта ветка предназначена для добавления, изменения конфигурации и удаления функций. Эта ветка является частью ветки разработки. После того, как все изменения будут внесены, разработчики включают ее обратно в ветку разработки.
Experimental-ветка
. Эта ветка выступает в качестве площадки для разработки новых функций или реализации каких-то своих идей, которые не являются частью релиза или спринта. Эта ветка предназначена для испытания новых вещей.
WIP-ветка.
Разработчики используют WIP-ветку (Work In Progress – незавершенные работы) для разработки или испытания новых функций. Эти ветки не обязательно должны являться частью обычного рабочего процесса разработки. Они создаются для отдельно взятого проекта и зачастую бывают неофициальными, безо всяких конкретных или стандартизированных правил.
Merging-ветка
. Это временная ветка, которая используется для разрешения конфликтов слияния. Такие конфликты могут возникать при добавлении последней разработки и feature или hotfix-ветки в другую ветку. Эта ветка также полезна при объединении двух feature-ветвей, разработанных несколькими участниками. Этот процесс включает в себя слияние, проверку и одобрения окончательного варианта изменений.
Этот далеко не полный список. Существует множество других неплохих форматов и соглашений о присвоении имен для временных ветвей какого-то конкретного проекта.
На следующей диаграмме показан пример рабочего процесса в репозитории Git с несколькими постоянными и временными ветками:
Соглашения о присвоении имен веткам Git
Большая часть соглашений о присвоении имен веткам, как правило, определяются самим проектом или командой. Вы можете использовать те имена, которые вам больше всего подходят, но при условии, что вы будете придерживаться единого стиля на протяжении всего проекта.
Ниже представлены несколько основных соглашений о присвоении имен веткам Git, которые многие разработчики применяют при работе в системе контроля версий.
Использование дефисов и слешей в качестве разделителей
Одно из самых распространенных соглашений о присвоении имен – это использование слеша (/) или дефиса (-) в качестве разделителя в имени ветки. Эти символы облегчают чтение названия ветки за счет того, вам не нужно разделять слова в уме.
Например, сравните следующие имена ветвей:
featurenewuserregistrationworkflowwithemailverification
и
feature/new-user-registration-workflow-with-email-verification
Данное имя ветки является описательным и содержит информацию о своей функции, в данном случае – добавить новый рабочий процесс регистрации пользователя с проверкой электронной почты. При этом гораздо проще разобрать для чего она нужна, когда в названии используются разделители – слеш и дефис.
Помимо этого, старайтесь давать веткам более короткие имена. Чтобы улучшить приведенное выше имя, его можно сократить:
feature/email-verification-workflow
Итак, основными преимуществами использования разделителей в названии ветки являются:
Улучшенная читаемость, препятствующая возникновению путаницы
Более легкое управление, особенно при работе с большим количеством веток
Разделяя слова дефисами и слешами и используя строчные буквы, вы можете обеспечить лучшую читаемость.
Примечание
: не используйте пробелы в именах ветвей, так как в таком случае будет создан «осиротевший» коммит, к которому будет невозможно получить доступ ни из одного коммита в репозитории. Также избегайте использования каких-либо других специальных символов, помимо дефисов и слешей, так как они могут вызвать проблемы в Git.
Использование
цифр
Если для создания трабл-тикетов и разработки новых функций вы используете Jira, то будет полезно добавить номер тикета к названию ветки. Номер тикета в названии ветки Git помогает отслеживать ход работы над этой веткой. Кроме того, номера тикетов Jira уникальны, так что вероятность, что две ветки будут иметь одинаковые имена, нулевая.
Если вы пользуетесь внешней системой для отслеживания хода разработки, то вы можете указать в названии ветки внешний ID отслеживания. Но не используйте только цифры. Дайте все же ветке описательное имя, чтобы пояснить, в чем ее назначение.
Например, следующее название ветки содержит ID отслеживания и описание:
wip/8712-add-login-module
Из названия мы можем понять, что это WIP-ветка. Далее следует ID отслеживания и описание ее назначения.
Использование ключевых слов
Чаще всего название ветки начинается с ключевого слова, которое определяет назначение ветки. Как правило, эти ключевые слова обозначают тип ветки, например,
bugfix
hotfix
wip
feature и т.д.
Такое распределение по категориям помогает разработчикам, совместно работающим над проектом, понимать назначение той или иной ветки. Ключевые слова обычно отделяются от остальной части названия слешем (/).
Например, в начале следующего имени ветки используется ключевое слово, показывающее ее назначение:
bugfix/fix-login-error
Задача ветки – исправление ошибки авторизации. Она создана именно для этой цели.
Использование имени автора
Еще одно соглашение – это использование имени автора в названии ветки Git. Таким образом, можно пояснить, кто из разработчиков работал над этой веткой, а также легко отслеживать, кто работает над той или иной функцией. Имя автора, как правило, пишется в самом начале.
Например,
johndoe/feature/add-user-profile
Здесь имя ветки начинается с имени автора, за которым следует слеш, отделяющий его от типа ветки. Далее идет назначение ветки – добавить функцию создания профиля пользователя.
Длина имени
Старайтесь делать так, чтобы имена ветвей были описательными, но при этом максимально короткими и простыми, особенно если над проектом работают несколько человек. Разработчики должны иметь возможность, глядя на название ветки, быстро определить, для чего нужна она ветка.
Например, для того, чтобы улучшить вот это имя:
feature/user-authentication-system-with-two-factor-authentication
Мы можем его укоротить до вот такого варианта:
feature/2fa-auth
Если имена веток будут слишком длинные, трудно будет отличить их друг от друга, особенно по мере увеличения сложности проекта и, соответственно, количества ветвей. Работать с короткими и простыми именами гораздо проще.
Одновременное использование нескольких соглашений о присвоении имен
Можно использовать сразу несколько соглашений о присвоении имен веткам Git. Но все-таки не стоит применять все эти правила к каждой ветке. Вместо этого постарайтесь скомбинировать их в привычной для себя манере и доступной форме, чтобы сохранить их читаемость.
Например, рассмотрим следующее имя ветки:
feature/user-registration-system/bugfix/T-133-issue123
В этом имени используется несколько соглашений. Оно говорит нам о том, что это feature-ветка, где разрабатывается функция регистрации пользователей. При этом внутри нее есть еще одна ветка – bugfix-ветка с тикетом Jira под номером 133 для исправления ошибки 123.
Несмотря на то, что название описательное, оно довольно длинное и с ним будет сложно работать. Впрочем, мы можем его укоротить до вот такого варианта:
feature/T-133-bugfix
Такой укороченный вариант имени по-прежнему дает нам необходимый контекст, но с ним будет гораздо проще работать, так как в нем используется меньше соглашений. По сути, ваша команда сама должна решить, сколько информации включать в имена и каких соглашений придерживаться. Таким образом, вы сможете гарантировать, что репозиторий будет оставаться структурированным и простым в управлении.
Заключение
Git – это отличный вариант для разработчиков, которые хотят совместно работать над одной кодовой базой. В этой статье мы перечислили соглашения, которые вы можете использовать для именования ветвей, а также методические рекомендации, следуя которым, вы сможете сохранить структуру и качество своей кодовой базы.