По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Спешим рассказать тебе дорогой читатель о том, как установить бесплатный Open Source, который поможет в организации кол-центра (Call Center). Речь пойдёт о решении GoAutoDial. В дальнейшем, планируем дополнить цикл статей о нём обзором, настройкой и примерами использования. /p> Как заявляет разработчик на своём сайте, GoAutoDial – это open source продукт, сочетающий в себе функционал предиктивного дайлера и IVR/ACD система на базе ОС CentOS, предназначенная для организации работы кол-центра. В качестве, собственно, системы для совершения звонков, «под капотом» GoAutoDial находится Asterisk версии 1.8. Установка В зависимости от того, какую систему Вы используете (32 или 64-бит), скачайте http://www.goautodial.org/projects/goautodialce последнюю версию образа GoAutoDial CE 3.3 с сайта разработчика: Запишите данный образ на диск или же загрузите на виртуальную машину и настройте свой сервер так, чтобы он загружался с диска с образом. Перед дальнейшей установкой, убедитесь, что сервер подключен к сети. Запустите сервер с GoAutoDial и нажмите Enter, когда увидите следующее окно: Далее Вам будет предложено ввести пароль для пользователя root: После чего начнётся процесс установки. У нас он занял всего на всего 4 минуты. Однако, длительность установки будет зависеть от технических характеристик сервера. Когда процесс установки завершится, Вы увидите вот такое окно и предложение выполнить перезагрузку сервера. Жмём на кнопку Reboot: На данном этапе, следует вытащить установочный диск из дисковода сервера или виртуального дисковода, если Вы устанавливаете GoAutoDial на вирутальную машину. После перезагрузки, вам будет предложено подключиться к консоли сервера, для этого введите реквизиты доступа пользователя root, которые вводили на начальном этапе установки. После успешной авторизации, Вы увидите сообщение, в котором будут указаны данные для подключения к web-интерфейсу GoAutoDial, его IP-адрес, который он получил по DHCP, а также логин и пароль администратора системы. На данном этапе, рекомендуется сделать полный апдейт сервера, для этого введите команду yum update -y Но поскольку система у нас шла с CentOS 5, который уже EOL, то мы получим ошибки следующего вида: YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. Invalid release/ removing mirrorlist with no valid mirrors: /var/cache/yum/base/mirrorlist.txt Error: Cannot find a valid baseurl for repo: base А чтобы от них избавиться, введите следующие команды: Внимание! Если в процессе ввода команд возникнут ошибки No such file or directory, то просто создайте те директории, на которые он будет ругаться и повторите ввод команды. Если вы используете 32-битную систему, то замените часть командыx86_64 на i386 # echo "http://vault.centos.org/5.11/os/x86_64/" > /var/cache/yum/base/mirrorlist.txt # echo "http://vault.centos.org/5.11/extras/x86_64/" > /var/cache/yum/extras/mirrorlist.txt # echo "http://vault.centos.org/5.11/updates/x86_64/" > /var/cache/yum/updates/mirrorlist.txt Далее вводим yum makecache и повторяем ввод yum update -y, который на этот раз должен удачно сработать и запустить обновление системы. Чтобы установить статический IP адрес, сконфигурировать DNS, настроить Firewall и автоматический запуск сервисов, а также установить настройки часовых поясов, введите команду setup в консоли. Перед Вами откроется графический интерфейс следующего вида: После любых изменений, выполненных в данном интерфейсе, рекомендуется выполнить перезапуск сервисов service mysqld restart и service httpd restart. Наконец, можно открыть любой браузер и подключиться к web-интерфейсу администратора GoAutoDial. Для этого введите IP-адрес из сообщения после первого подключения к консоли или же, если вы установили статический IP-адрес, то введите его в адресную строку браузера. Пароль и логин по умолчанию для подключения к web-интерфейсу администратора - admin/ goautodial.
img
Настроить бэкэнд-службу с нуля сложно. Для облегчения работы можно использовать Firebase, но это не единственное в своем роде решение. В данном материале рассмотрим альтернативные решения бэкэнда для веб-приложений и мобильных приложений. Что такое бэкэнд? Бэкэнд - это программное обеспечение, которое обрабатывает данные мобильного или веб-приложения. Он содержит всю логику доступа и управления данными, к которым обычные пользователи не могут получить доступ. Бэкэнд также отвечает за обработку веб-запросов и веб-ответов. Обычно он известен как часть приложения, которое скрыто от пользователя, и он взаимодействует с фронтэндом (то что пользователь видит), чтобы отобразить запрашиваемые данные. Для создания бэкэнд-решений можно использовать несколько языков программирования, таких как Python, JavaScript и PHP. В дополнение к этим языкам, вы можете использовать серверные фреймворки, такие как Django, NireJS и Laravel, которые обеспечивают «стандартный» способ построения сложных приложений. Чтобы создать пользовательское бэкэнд-решение, требуются хорошие навыки работы с некоторыми из упомянутых выше языков программирования, и, что более важно, много времени. Если вы хотите пропустить этот процесс и сосредоточиться на скорейшем завершении проекта, вы можете использовать готовое к использованию бэкэнд-решение или, если вы предпочитаете модный термин «бэкэнд как услуга» (Baas - Backend-as-a-service). Наиболее популярным сервисом является Firebase, консолидированный продукт, поддерживаемый Google, но у него есть некоторые недостатки: Ограниченная миграция данных Ограниченное хранение данных Больше нацелен на Android (большие улучшения на iOS в последние месяцы) Основная служба не является открытой Для хранения данных приложения и управления ими вы полагаетесь на внешнюю службу Firebase - отличный продукт, особенно если вы только начинаете, но, чтобы иметь выбор, важно знать некоторые альтернативы. 1. Appwrite Appwrite - это комплексное бэкэнд-решение практически для каждого веб- или мобильного приложения, о создании которого вы мечтаете. Он является решением с открытым исходным кодом, имеет нулевые зависимости и легко интегрируется (через SDK) с некоторыми наиболее популярными инструментами и языками. Appwrite - это автономный бэкэнд сервер, который поставляется в виде Docker-образа. Это означает, что ее можно установить в любой ОС, поддерживающей интерфейс командной строки Docker. Эта кроссплатформенная функциональность позволяет запускать Appwrite на локальном рабочем столе или на любом облачном сервере. Appwrite поставляется со встроенной панелью, которая позволяет управлять приложениями как проектами. Каждый проект может интегрироваться непосредственно с вашим приложением. Другие интересные особенности Appwrite: Простота Отличная документация Кроссплатформенность Нулевые зависимости (кроме Docker) 2. Supabase Supabase - это альтернатива Firebase с открытым исходным кодом, которая выполняет повторяющиеся операции CRUD и позволяет сосредоточиться на вашем продукте. Помимо возможности самостоятельного хостинга, Как и Appwrite, Supabase можно развернуть локально. Но в отличии от первого, Supabase также предлагается в облачном варианте. Он предоставляет все бэкэнд-услуги, необходимые для создания продукта. Вот основные: База данных Postgres Идентификация Хранение файлов Автоматически созданные API Вы можете создать учетную запись в GitHub, выбрать бесплатный план и создать приложение за считанные минуты. Supabase поставляется с панелью мониторинга, включающая редактор таблиц (аналогично электронной таблице), встроенный редактор SQL и управление пользователями. Имеется обширная официальная документация, которая позволяет быстро начать разработку приложения на этой платформе. 3. Parse Platform Parse Platform – это полный стек приложений. Его основным продуктом является сервер Parse - бэкэнд сервер с открытым исходным кодом и автономным хостингом, который может быть развернут в любой инфраструктуре, поддерживающей Node.js. Parse Server использует MongoDB или Postgres в качестве базы данных и позволяет использовать собственную инфраструктуру для развертывания внутреннего сервера. Если вы хотите разработать приложение локально, вы можете сделать это с помощью Node. ParseplatformIt имеет несколько SDK с открытым исходным кодом, которые позволяют интегрировать почти все существующие веб-приложения или мобильные приложения за пару команд. Самое интересное в Parse - это широкое сообщество. Они создали множество проектов для расширения функциональности Parse, таких как адаптер MySQL или Live Query for .Net. 4. Cloudboost Cloudboost - это полнофункциональный JavaScript бэкэнд, включающий все инструменты и инфраструктуру, необходимые для создания современных веб-приложений и мобильных приложений. При реализации основных функция вроде поиск или аутентификация пользователей, задачу целостности данных это решение берёт на себя. Все находится на одной платформе, поэтому вы экономите много времени и инвестируете в разработку своего приложения. Главный недостаток: он не является ни открытым, ни бесплатным. 5. Nhost Хотите использовать современный бэкэнд для создания современных приложений? Если да, Nhost то, что вам нужно. Вдохновленный от Firebase, это готовый к производству бэкэнд, который включает базу данных Postgres, Hasura, GraphQL, встроенную аутентификацию и хранилище. Как и в случае с каждым из представленных до сих пор бэкэнд-решений, оно предлагает набор SDK для интеграции вашего приложения. Это решение с открытым исходным кодом, но он предлагает облачную версию, которую вы можете начать использовать бесплатно и выбрать план после того, как вы попробуете его функции. Лучше всего в Nhost то, что у вас есть полный доступ к вашим данным (в отличии от Firebase), и вы можете экспортировать их в любое время. Nhost только становится, и вы можете наблюдать за их прогрессом и статистикой на их сайте. Заключение Backend-as-a-service позволяет делегировать базовае функции приложения и стандартные операции CRUD третьей стороне, чтобы сосредоточиться на создании наилучшего проекта за меньшее время.
img
Привет, сегодня расскажем что такое база данных и SQL. У современных баз данных куча нюансов - погнали разбираться. Представь - собираешь ты деньги на подарок корешу, и записываешь на бумажке, кто сколько скинул. Табличка с денежками организована, разделена по именам и сумме долга, и имеет удобную структуру - ну вот оно, это и есть база данных! Ага, теперь, перемещаемся в цифровое пространство и заводим целый эксель файл для этого дела. Стало удобнее, можно редактировать, сортировать и даже данные удалять! Круто! Но достаточно ли этого для роста этой базы данных? Нет. Со временем данных становится так много, что админам приходится связывать их друг с другом, а тут одним эксель файлом уже не обойтись. Представим, решили вы сделать свой аналог ютуба, как будете хранить инфу о пользователях? Список юзеров, там, каналы, кто на что подписан, лайки и вот это все. Сложить это все в одну таблицу? Будет неудобно и медленно работать. Очевидно, надо разделить сущности на несколько таблиц - юзеры, каналы и видосы: Теперь свяжем данные между собой и добавим информацию о том, кто создал канал, и на каком канале залили видео. Ага, получились связанные таблицы. Связанные, от слова связь. А связь, это по-английски relation. А в айти тусовке они так и называются - реляционные базы данных, и это один самых распространенных типов баз данных. Еще есть нереляционные базы данных, о них подробнее можно прочитать в этой статье про NoSQL. Уф, ну теперь с данными стало гораздо удобнее работать, и мы избежали большой таблицы с повторяющимися строчками, разбив все на несколько табличек. Такой процесс еще называется нормализацией, когда мы избавляемся от избыточных данных. Ну и как раз для этого мы ввели в каждой таблице специальное поле - ID, которое идентифицирует каждую запись. Этот айди называется Primary Key, он же “первичный ключ”. А в таблице которая будет на него ссылаться, он будет называться Foreign Key, или по-русски “внешний ключ”. Нырнем в детали и поговорим про типы связей между таблицами. Первый тип называется “Один-ко-многим” или “многие-к-одному” (One-to-Many или Many-to-One). В нашем примере, у каждого видео может быть только один канал, где оно выложено, но на одном канале может быть много видео, поэтому в двух последних строках ID канала у нас повторяется, верно? Отношения «один-ко-многим» также можно рассматривать как отношения «многие-к-одному», в зависимости от того, с какой стороны вы на это смотрите. Второй тип связей называется “один-к-одному” (One-to-One) - классические табличные отношения. Вообще, это редко используемый тип связи, обычно его делают для безопасности. Это как если на нашем аналоге ютуба, мы разрешили бы создавать только один канал одному пользователю и в таблице с каналами ID создателя не могло повторяться. Такое себе, согласен? В таком случае вообще можно было бы обойтись и одной таблицей. Ну и третий тип связей, это “многие ко многим” (Many-to-many). Это когда у нас появляется промежуточная таблица связей, которая как бы соединяет два отношения “один ко многим”, которые мы обсудили в начале разбора типов связей. Давайте сделаем таблицу с лайками балалайками, где будем хранить ID пользователей и ID видео, к которым они поставили лайк: А вот так они связан: каждый пользователь может поставить лайк каждому видео. Теперь вопрос - а где все это хранить? Не в экселе же. И тут на сцену выходит термин СУБД, она же система управления базами данных - это программа, которая позволяет создавать, редактировать и администрировать реляционную базу. Ну и для управления всей этой петрушкой используется язык структурированных запросов, SQL (Structured Query Language) эскюэль или сиквел, как иногда его называют за рубежом. Он очень простой и понятный, вот смотри - чтобы найти названия всех видео с одного канала, нам нужно выполнить следующий запрос: SELECT name FROM videos WHERE channel_id = 201 То есть мы буквально говорим: выбери (SELECT) имена из (FROM) таблицы видео, где (WHERE) айдишник (ID) канала равен 201. Если вы хотите взять данные из нескольких таблиц и объединить результат, то нужно использовать в запрос параметр JOIN (от английского соединить). Вот такая упрощающая жизнь админам аналогия с разговорным языком. Так, SQL конечно позволяет добавлять, удалять и изменять данные и сами таблицы. Но важно не забывать про схему базы данных (Database schema), которая служит для описания структуры таблицы, ее полей и ограничений. Прикол в том, что если вам потребуется добавить или убрать столбец в таблице, то это изменение коснется вообще всех данных в таблице, таким образом если мы добавляем новый столбец, то он теперь будет присутствовать в каждой строке. Окей, а для чего вообще нужны ограничения? Для целостности твоих данных. Помнишь мы рассказали про первичный и внешний ключ? Так вот, благодаря им мы можем удостовериться, что в таблицу не попадет запись, которая ссылается на несуществующий айдишник. Или различные ограничения полей, которые не дадут записать дублирующие или пустые данные в нашу базу (Not NULL и Unique). И еще: транзакции. Эта штука, которая позволяет как бы склеить несколько SQL запросов в один. Ну вот представь такую задачку: вставить данные в первую таблицу, а во второй указать ID вставленной записи. Если ты делаешь это без использования транзакций, а во время второго этапа у тебя отвалится интернет, то первая запись попадет в базу, а вторая нет. Ага, появляется интернет, и ты с улыбкой на лице идешь снова выполнить эти запросы, только на этот раз получишь ошибку, что такая запись уже есть, ибо первая то уже в базе! А в случае использования транзакций, при получении ошибки, мы откатимся до того момента, который был до начала транзакции. А еще все эти радости помогают реляционным БД (базам данных) соответствовать так называемым требованиям ACID, которые нужны для сохранности данных - это очень важно в банковской отрасли, или любой другой, где целостность и сохранность данных супер важны. Давай разберемся с аббревиатурой: Atomicity — атомарность, или же проще говоря, непрерывность: это как раз про транзакции, которые мы обсудили только что. Либо операция выполняется целиком, либо никак. Consistency — согласованность: данные, записываемые в таблицу должны соответствовать всем выставленным правилам и ограничениям, помнишь, мы говорили про первичный и внешний ключи, а также про уникальность? Isolation — изолированность: если вы гоняете тонну транзакций одновременно, они не должны пересекаться и влиять друг на друга. Это очень важно для высоконагруженных баз Durability — надежность: если мы получили подтверждение, что транзакция выполнена, то значит наши данные в сохранности, даже если после этого произошел сбой. Ну и в качестве примеров таких баз данных назовем: Microsoft SQL Server, Oracle Database, MySQL, MariaDB и PostgreSQL.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59