Что такое phoenix browser
Phoenix Browser Updater что это за программа? (phoenix.exe)
Анализируя названия Phoenix Browser Updater можно предположить, что это модуль обновления малоизвестного браузера Phoenix. По данным в интернете в планировщике задач может быть задание с названием Phoenix Browser Updater. Папка данной программы:
C:\Users\User\AppData\Local\Phoenix Browser Updater
Есть вероятность что данная программа устанавливает рекламные расширения в браузер или сомнительные программы на ПК.
Phoenix Browser Updater (PBU) не является вирусом, однако может показывать рекламу или устанавливать другие рекламные модули, среди которых также могут быть расширения к браузерам и вредоносные ссылки в ярлыках. Подобное ПО попадает на компьютер при загрузке программ из сомнительных источников и при отсутствии должной защиты Windows.
В диспетчере задач работает под процессом Phoenix Browser Updater.exe или просто phoenix.exe.
Чем опасна программа Phoenix Browser Updater?
Данное ПО может попасть на ПК при помощи других программ, а точнее вместе с ними.
Недоброжелатели склеивают обычные программы вместе с рекламными модулями, цель которых показать вам рекламу в браузере, на рабочем столе, или иным способом.
Есть еще похожая программа — Twilight Pretty Search. По информации в интернете относится к рекламному ПО. Не наносит вреда системе, но при этом возможно задействует механизмы показа рекламы. Приведенные утилиты в данной статье способы удалить в том числе и Twilight Pretty Search.
Примеры несвойственной рекламы
Как удалить Phoenix Browser Updater?
Позже выяснилось, что Phoenix Browser — действительно браузер, работающий предположительно на Android. Возможно есть версия и под Windows. Тем не менее об этой программе больше отрицательных отзывов, чем положительных.
Для удаления сперва проанализируйте автозагрузку:
При возможности перед удалением создайте контрольную точку восстановления. В случае проблем вы всегда сможете откатиться назад.
Далее просканируйте ПК тремя специальными утилитами (лучшие на сегодняшний день). Утилиты проверят ПК — папки браузеров, ярлыки, системные папки, файлы, автозагрузку.
Вот они, лучшие утилиты:
В качестве защиты рекомендую использовать бесплатную версию антивируса Касперского. При моем тестировании антивирус не грузил ПК и работал быстро. Скорость проверки разумеется зависит от скорости работы вашего диска.
Удаление обычным способом
Можно попробовать удалить ПО и при помощи обычного способа. Зажмите Win + R, потом появится окошко Выполнить, вставьте в него команду:
После этого появится окно со списком установленных программ. Найдите Phoenix Browser Updater, кликните правой кнопкой по программе, выберите Удалить и следуйте дальнейшим инструкциям.
Удаление Phoenix Browser Updater стандартным способом
Обзор Fenix Browser — быстрый, яркий, скрытный
Fenix Browser от Dimitar Reloaded претендует на звание одного из самых быстрых мобильных браузеров на Android. Он выделяется необычным интерфейсом и принципами функционирования. Это приложение идеально оптимизировано под работу на планшетах и прошло проверку на совместимость со многими устройствами.
Один из самых скоростных движков позволяет даже на смартфонах без затруднений просматривать насыщенные разнообразным контентом сайты. Пользователи с легкой паранойей могут активировать режим инкогнито и путешествовать по интернету невидимкой, нигде не оставляя следов. Также Fenix Browser позволяет просматривать социальные сети без авторизации.
Для сохранения интересных посещенных страниц можно воспользоваться менеджером закладок, встроенным в браузер, а самые любимые сайты будут запускаться с домашней страницы при помощи функции SpeedDial.
Визуальные решения этого приложения выгодно отличают его от конкурентов. Многие пользователи пишут о слишком навязчивом дизайне главной страницы и интерфейса браузера, который «ворует» немало драгоценного пространства у просматриваемого сайта. Впрочем, можно постараться оптимизировать Fenix Browser под себя, настроив размер окон, шрифты, цветовую схему и другие параметры. После такой кастомизации работа с браузеро м станет более удобной.
Одно из основных достоинств Fenix Browser – возможность работать в шести вкладках одновременно. Функция блокировки неиспользуемых в данный момент вкладок позволяет не потерять важную информацию, ведь при работе на небольшом экране можно случайным движением что-нибудь закрыть.
Разработчики Fenix Browser хотели создать продукт, значительно отличающийся от аналогов, в первую очередь, визуально. В целом, им это удалось, но над некоторыми недостатками приложения еще следует поработать: именно внешняя вычурность мешает комфортно серфить по просторам интернета.
После подготовки обзора Fenix Browser был временно удален из Google Play
TIMON SOFTWARE CO., LTD
Снимки экрана
Описание
Phoenix Browser is a fast, free, full-featured web browser that provides maximum privacy and security.
Fast Browsing and Downloads: Access websites, download multiple files (videos, audio, documents and more) with the speed of light. Download online videos easily from lots of websites.
Ad Block: Block annoying adverts and popups, save time and increase loading speed.
Ad Block blocks various forms of annoying ads, pop-ups and banners to make your browsing comfortable. It not only speeds up the page loading speed but also reduces Internet data usage.
Data Saver: Stream movies, download files, browse more with less data on any website.
Phoenix Browser could compress data, speed up navigation and help you save a lot of cellular data traffic.
Incognito Browsing
Incognito tab makes your browsing experience perfectly private without leaving any history, cookies, cache, etc.
Search Engines
Switch search engines according to your preference. We support Google, Yahoo, Ask, Yandex, AOL, DuckDuckGo and Bing.
Multi-Tab Manager
Easy switching of pages from multiple websites. Using multi-tab manager will make your browsing experience smoother.
Reader Mode
No Image Mode disables image and video loading to save data on a poor network connection.
Night/Bright Mode
Night Mode protects your eyes when browsing in darkness. Bright mode prevents the screen from going dark.
Find in Page/Translate
Search to find whatever you need in website pages, and translation function is supported.
Free Unlimited VPN: taking your Internet freedom and security to the next level
We are a group of enthusiasts whose main concern is the current lack of Internet privacy. Most private web browsers out there are very simple and do not offer extra features like regular browsers do. But private browsing should not be boring. That’s why we have created Phoenix Browser. Our mission is to keep you safe, entertained, and make your web browsing as private as you want it to be.
Создание движка для блога с помощью Phoenix и Elixir / Часть 1. Вступление
От переводчика: «Elixir и Phoenix — прекрасный пример того, куда движется современная веб-разработка. Уже сейчас эти инструменты предоставляют качественный доступ к технологиям реального времени для веб-приложений. Сайты с повышенной интерактивностью, многопользовательские браузерные игры, микросервисы — те направления, в которых данные технологии сослужат хорошую службу. Далее представлен перевод серии из 11 статей, подробно описывающих аспекты разработки на фреймворке Феникс казалось бы такой тривиальной вещи, как блоговый движок. Но не спешите кукситься, будет действительно интересно, особенно если статьи побудят вас обратить внимание на Эликсир либо стать его последователями».
На данный момент наше приложение основано на:
Установка Phoenix
Лучшая инструкция по установке Phoenix находится на его официальном сайте.
Шаг 1. Добавление постов
Начнём с запуска mix-задачи для создания нового проекта под названием «pxblog». Для этого выполним команду `mix phoenix.new [project] [command]`. Отвечаем утвердительно на все вопросы, так как нам подойдут настройки по умолчанию.
Мы должны увидеть кучу информации о том, что создание нашего проекта было завершено, а также команды для подготовительной работы. Выполняем их поочерёдно.
Если у вас не создана база данных Postgres или приложение не настроено на работу с ней, команда `mix ecto.create` выкинет ошибку. Для её исправления откройте файл config/dev.exs и просто измените имя пользователя и пароль для роли, которая имеет права на создание базы данных:
Когда всё заработает, давайте запустим сервер и убедимся, что всё хорошо.
Для этого перейдём по адресу http://localhost:4000/ и увидим страницу Welcome to Phoenix!. Хорошая основа готова. Давайте добавим к ней главный скаффолд для работы с постами, так как всё же у нас блоговый движок.
Воспользуемся встроенным в Phoenix генератором для создания Ecto-модели, миграции и интерфейса обработки CRUD-операций модуля Post. Так как на данный момент это очень и очень простой движок, то ограничимся заголовком и сообщением. Заголовок будет строкой, а сообщение — текстом. Команда, которая создаст это всё за нас довольно простая:
Получаем ошибку! Чтобы исправить её, а заодно сделать интерфейс постов доступным из браузера, давайте откроем файл web/router.ex, и добавим в root-скоуп следующую строчку:
Теперь можем ещё раз выполнить команду и убедиться, что наша миграция прошла успешно.
И, наконец, перезапускаем наш сервер заходим на страницу http://localhost:4000/posts, где мы должны увидеть заголовок Listing posts, а также список наших постов.
Немного повозившись мы получили возможность добавлять новые посты, редактировать их и удалять. Довольно круто для такой маленькой работы!
Шаг 1Б. Написание тестов для постов
Одной из прелестей работы со скаффолдами является то, что с самого начала мы получаем набор базовых тестов. Нам даже не нужно особо их изменять до тех пор, пока мы не начнём вносить серьёзные изменения в код самого приложения. Сейчас давайте разберём какие тесты были созданы, чтобы лучше понять как писать собственные.
Во-первых, откроем файл test/models/post_test.exs и взглянем на содержимое:
Давайте разбирать этот код по частям, чтобы понять, что же тут происходит.
Наконец, мы проверяем создание ревизии с недействительными параметрами, и вместо «утверждения», что ревизия валидная, выполняем обратную операцию refute.
Это очень хороший пример того, как написать тест модели. Теперь давайте посмотрим на тест контроллера. Взглянув на него мы должны увидеть примерно следующее:
Здесь используется Pxblog.ConnCase для получения специального DSL уровня контроллера. Остальные строки должны быть уже знакомы.
Посмотрим на первый тест:
Здесь мы захватываем переменную conn, которая должна быть отправлена через блок настройки в ConnCase. Я объясню это позже. Следущий шаг — воспользоваться одноименной подходящему HTTP-методу функцией, чтобы совершить запрос по нужному пути (GET-запрос к действию :index в нашем случае). Затем мы проверяем, что ответ данного действия возвращает HTML со статусом 200 («OK») и содержит фразу Listing posts.
Следующий тест по сути такой же, только уже проверяется действие new. Всё просто.
А здесь мы делаем что-то новенькое. Во-первых, отправляем POST-запрос со списком действительных параметров по адресу post_path. Мы ожидаем получить перенаправление на список постов (действие :index). Функция redirected_to принимает в качестве аргумента объект соединения, так как нам нужно знать, куда произошло перенаправление.
Наконец, мы утверждаем, что объект, представленный этими действительными параметрами был успешно добавлен в базу данных. Эта проверка осуществляется через запрос к репозиторию Ecto Repo на поиск модели Post, соответствующей нашим параметрам @valid_attrs.
Теперь снова попробуем создать пост, но уже с недействительным списком параметров @invalid_attrs, и проверим, что снова отобразится форма создания поста.
Чтобы протестировать действие show, нам нужно создать модель Post, с которой и будем работать. Затем вызовем функцию get с хелпером post_path, и убедимся, что возвращается соответствующий ресурс.
Также мы можем попытаться запросить путь к ресурсу, которого не существует, следующим образом:
Здесь используется другой шаблон записи теста, который на самом деле довольно прост для понимания. Мы описываем ожидание того, что запрос несуществующего ресурса приведёт к ошибке 404. Туда же передаём анонимную функцию, содержащую код, который при выполнении должен вернуть эту самую ошибку. Всё просто!
Остальные тесты лишь повторяют вышеперечисленное для оставшихся путей. А вот на удалении остановимся подробнее:
В целом, всё похоже, за исключением использования HTTP-метода delete. Мы утверждаем, что должны быть перенаправлены со страницы удаления обратно к списку постов. Ещё мы используем здесь новую фишку — «отвергаем» существование объекта Post с помощью функции refute.
Шаг 2. Добавляем пользователей
Для создания модели User, мы пройдём практически те же шаги, что и при создании модели постов, за исключением добавления других столбцов. Для начала выполним:
Далее откроем файл web/router.ex и добавим следующую строчку в тот же скоуп, что и ранее:
Синтаксис здесь определяет стандартный ресурсовый путь, где первым аргументом идёт URL, а вторым — имя класса контроллера. Затем выполним:
Наконец, перезагружаем сервер и проверяем http://localhost:4000/users. Теперь, помимо постов, мы имеем возможность добавлять и пользователей!
К сожалению, пока это не очень полезный блог. В конце концов, хоть мы и можем создавать пользователей (к сожалению, сейчас это сможет сделать любой), мы не можем даже войти. Кроме того, дайджест пароля не использует никаких алгоритмов шифрования. Мы тупо храним тот текст, что ввёл пользователь! Совсем не круто!
Давайте приведём этот экран в вид более похожий на регистрацию.
Наши тесты пользователей выглядят точно так же, как и то, что было автоматически сгенерировано для наших постов, так что пока мы оставим их в покое, до тех пор, пока не начнём модифицировать логику (а этим мы займёмся прямо сейчас!).
Шаг 3. Сохранение хеша пароля, вместо самого пароля
Открыв адрес /users/new, мы видим три поля: Username, Email и PasswordDigest. Но ведь когда вы регистрируетесь на других сайтах, вас просят ввести не дайджест пароля, а сам пароль вместе с его подтверждением! Как мы можем это исправить?
В файле web/templates/user/form.html.eex удалите следующие строки:
И добавьте на их место:
После обновления страницы (должно происходить автоматически) введите данные пользователя и нажмите кнопку Submit.
Это происходит потому, что мы используем поля пароль и подтверждение пароля, о которых приложению ничего не известно. Давайте писать код, решающий эту проблему.
Начнём с изменения схемы. В файле web/models/user.ex добавим пару строк:
Обратите внимание на добавление двух полей :password и :password_confirmation. Мы объявили их в качестве виртуальных полей, так как на самом деле их не существует в нашей базе данных, но они должны существовать как свойства в структуре User. Это также позволяет применять преобразования в нашей функции changeset.
Затем мы добавим :password и :password_confirmation в список обязательных полей:
Если вы сейчас попробуете запустить тесты из файла test/models/user_test.exs, то тест “changeset with valid attributes” упадёт. Это происходит потому, что мы добавили :password и :password_confirmation к обязательным параметрам, но не обновили @valid_attrs. Давайте изменим эту строчку:
Наши тесты моделей должны снова проходить! Теперь нужно починить тесты контроллеров. Внесём некоторые изменения в файл test/controllers/user_controller_test.exs. Вначале выделим валидные атрибуты для создания объекта в отдельную переменную:
Затем изменим наш тест на создание пользователя:
И тест на обновление пользователя:
После того, как наши тесты снова стали зелёными, нам нужно добавить в changeset функцию, преобразующую пароль в дайджест:
Пока мы просто стабим поведение нашей хеширующей функции. Первым делом давайте убедимся, что изменение ревизии происходит корректно. Вернёмся в браузер на страницу http://localhost:4000/users, кликнем на ссылку New user и создадим нового пользователя с любыми данными. Теперь в списке пользователей нас ожидает новая строка, дайджест пароля в которой равен ABCDE.
Снова запустим тесты этого файла. Они проходят, но не хватает теста на проверку работы функции hash_password. Давайте добавлять:
Это большой шаг вперёд для приложения, но не такой большой для безопасности! Нужно скорее исправить хеширование пароля на настоящее с использованием BCrypt, любезно предоставленной библиотекой Comeonin.
Для этого откройте файл mix.exs и добавьте :comeonin в список applications:
Также нам нужно изменить наши зависимости. Обратите внимание на <:comeonin, “
Наш старый метод hash_password неплох, но вообще-то нам нужно, чтобы пароль хешировался на самом деле. Так как мы добавили библиотеку Comeonin, которая предоставляет нам прекрасный модуль Bcrypt с методом hashpwsalt, который мы импортируем в нашу модель User. В файле web/models/user.ex добавьте приведённую ниже строчку сразу следом за use Pxblog.Web, :model:
Что мы сейчас сделали? Мы вытянули модуль Bcrypt из пространства имён Comeonin и импортировали метод hashpwsalt с арностью 1. А следующим кодом мы заставим функцию hash_password работать:
Предлагаю попробовать создать пользователя ещё раз! На этот раз, после регистрации мы должны увидеть шифрованный дайджест в поле password_digest!
Теперь давайте немного доработаем функцию hash_password. Во-первых, чтобы шифрование пароля не тормозило тестирование, необходимо внести изменения в настройки тестового окружения. Для этого откройте файл config/test.exs и добавьте следующую строчку в самый низ:
Это скажет библиотеке Comeonin не слишком сильно шифровать пароль во время выполнения тестов, поскольку в тестах нам важнее скорость, чем безопасность! А в продакшене (файл config/prod.exs) нам наоборот нужно усилить защиту:
Давайте напишем тест для вызова Comeonin. Мы сделаем его менее подробным, так как хотим лишь убедиться в работе шифрования. В файле test/models/user_test.exs:
Для улучшения покрытия тестами, давайте рассмотрим случай, когда строчка `if the password = get_change() не является истиной:
В данном случае поле password_digest должно оставаться пустым, что и происходит! Мы проделываем хорошую работу, покрывая наш код тестами!
Шаг 4. Давайте войдём!
Добавим новый контроллер SessionController и сопутствующее представление SessionView. Начнём с простого, а со временем придём к более правильной реализации.
Создайте файл web/controllers/session_controller.ex:
А также web/views/session_view.ex:
И напоследок web/templates/session/new.html.eex:
Следующую строку добавьте в скоуп «/»:
Тем самым мы включаем наш новый контроллер в маршрутизатор. Единственный путь, который нам сейчас понадобится, это new, что мы явно и указываем. Опять же, нам нужно получить наиболее устойчивый фундамент наиболее простыми методами.
Перейдя по адресу http://localhost:4000/sessions/new, мы должны увидеть под заголовком Phoenix framework подзаголовок Login.
Добавим сюда настоящую форму. Для этого создадим файл web/templates/session/form.html.eex:
И вызовем только что созданию форму в файле web/templates/session/new.html.eex с помощью всего лишь одной строчки:
Благодаря автоматической перезагрузке кода, на странице отобразится ошибка, так как мы ещё не определили переменную @changeset, которая как можно догадаться должна быть ревизией. Раз мы работаем с объектом, у которого есть поля :name и :password, давайте их и использовать!
В файле web/controllers/session_controller.ex нам необходимо добавить алиас модели User, чтобы мы спокойно могли к ней обращаться дальше. В верхней части нашего класса, прямо под строкой use Pxblog.Web, :controller добавьте следующее:
И в функции new измените вызов рендера, как показано ниже:
Мы должны передать сюда объект соединения, шаблон который мы хотим отрендерить (без расширения eex) и список дополнительных переменных, которые будут использоваться внутри шаблона. В данном случае нам нужно указать changeset: и передать ему ревизию Ecto для User с пустой структурой пользователя.
Обновим страничку. Теперь мы должны увидеть другую ошибку, выглядящую следующим образом:
В нашей форме мы ссылаемся на путь, которого пока не существует. Мы используем хелпер session_path, передавая ему объект @conn, но затем указываем путь :create, который ещё только предстоит создать.
Половина пути пройдена. Теперь давайте реализуем возможность реального входа с использованием сессии. Для этого изменим наши пути.
В файле web/router.ex включим :create в описание SessionController:
В файле web/controllers/session_controller.ex импортируем функцию checkpw из модуля Bcrypt библиотеки Comeonin:
В этой строке говорится “Импортируй из модуля Comeonin.Bcrypt только функцию checkpw с арностью 2″.
А затем подключим плаг scrub_params, который будет работать с пользовательскими данными. Добавим перед нашими функциями:
scrub_params — это специальная функция, которая очищает пользовательский ввод. В случае, когда, например, какой-либо атрибут передаётся как пустая строка, scrub_params сконвертирует её в значение nil, чтобы избежать создание в базе данных записей с пустыми строками.
Следом добавим функцию для обработки действия create. Расположим её внизу модуля SessionController. Здесь будет много кода, так что давайте разберём его по частям.
В файле web/controllers/session_controller.ex:
Первый кусочек кода Repo.get_by(User, username: user_params[“username”]) вытаскивает подходящего пользователя User из нашего репозитория Ecto Repo, если username совпадает либо возвращает nil.
Вот небольшой кусочек вывода, чтобы проверить это поведение:
Затем мы берем пользователя, и передаём его по цепочке в функцию sign_in. Мы до сих пор её не написали, так что давайте этим и займемся!
Главное, на что нужно обратить внимание — это порядок, в котором определены эти функции. Первая из них имеет охранное условие, следовательно этот метод будет выполняться только в случае истинности этого условия. Так что, если мы не нашли пользователя, то осуществим перенаправление обратно к root_path с соответствующим сообщением.
Вторая функция будет обрабатывать все остальные сценарии (когда охранное условие ложно). Мы проверяем пароль функцией checkpw. Если он правильный, то записываем пользователя в переменную сессии current_user и осуществляем перенаправление с сообщением об успешном входе. В противном случае, мы очищаем текущий сеанс пользователя, устанавливаем сообщение об ошибке, и перенаправляем к корню.
Мы можем зайти на страницу http://localhost:4000/sessions/new и проверить как оно работает. С правильными данными мы войдём внутрь, а с неправильными получим ошибку.
Нам также нужно написать тесты на этот контроллер. Создадим файл test/controllers/session_controller_test.exs и заполним его следующим кодом:
Начинаем со стандартного блока setup и довольно обычной проверки GET-запроса. Тест на создание выглядит более интересным:
Первая строчка — это отправка POST-запроса на путь создания сессии. Затем идут проверки, установилась ли переменная сессии current_user, появилось сообщение о входе, и, наконец, осуществилось ли перенаправление. В остальных тестах мы точно так же проверяем другие пути, куда может попасть функция sign_in. Опять же всё очень просто!
Шаг 5. Улучшаем нашего current_user
Давайте изменим основной шаблон так, чтобы он отображал либо имя пользователя, либо ссылку на вход, в зависимости от того, вошёл пользователь или нет.
Для этого в файл web/views/layout_view.ex добавим хелпер, который облегчит получение информации о текущем пользователе:
Теперь откроем файл web/templates/layout/app.html.eex и вместо ссылки Get Started добавим следующее:
Давайте снова разбирать код по шагам. Одной из первых вещей, которую нам нужно сделать — это выяснить кто текущий пользователь, предполагая, что он уже вошёл в систему. Сначала сделаем решение в лоб, а рефакторингом займёмся после. Установим пользователя из сессии прямо в нашем шаблоне. Функция get_session — это часть объекта Conn.
Если пользователь вошёл в систему, нам нужно показывать ему ссылку на выход. Мы будем рассматривать сессию в качестве обычного ресурса, так что для выхода мы просто удалим сессию с помощью ссылки на это действие.
Нам также нужно вывести имя текущего пользователя. Мы храним структуру пользователя в сессионной переменной current_user, так что у нас есть возможность получить username через user.username.
Если мы не смогли найти пользователя, то просто показываем ссылку на вход. Здесь мы снова рассматриваем сессию как ресурс, так что new предоставит правильный путь для создания новой сессии.
Вы наверное заметили, что после обновления страницы мы получаем ещё одно сообщение с ошибкой об отсутствующей функции. Давайте подключим требуемый путь, чтобы Phoenix был счастлив!
В файле web/router.ex добавляем к маршрутам сессии также и :delete:
Ещё нужно изменить контроллер. В файл web/controllers/session_controller.ex добавьте следующее:
Так как мы только что удалили ключ current_user, нам не важно какие параметры приходят, поэтому помечаем их знаком подчёркивания вначале как неиспользуемые. Также мы установили сообщение об успешном выходе и осуществили перенаправление в список постов.
Теперь мы можем войти, выйти и проверить неудачный вход. Всё идёт к лучшему! Но прежде нам нужно написать несколько тестов. Мы начнём с тестов для нашего LayoutView. Первое, что мы собираемся сделать, это прописать алиасы для модулей LayoutView и User, чтобы сократить код. Далее в блоке настройки мы создаём пользователя и добавляем его в базу данных. А затем возвращаем стандартный кортеж .
Теперь рассмотрим сами тесты. В первом из них мы создаём сессию и утверждаем, что функция LayoutView.current_user должна вернуть определённые данные. Во втором же рассмотрим обратную ситуацию. Мы явно удаляем сессию и опровергаем, что функция current_user возвращает пользователя.
Также мы добавили действие delete в SessionController, следовательно на это тоже нужно написать тест:
Здесь мы убеждаемся, что current_user из сессии является пустым, а также проверяем возвращаемое flash-сообщение и перенаправление.
На этом первая часть подошла к концу.
Важное заключение от переводчика
Мною была проделана огромная работа по переводу как этой статьи, так и переводу всей серии. Чем я продолжаю заниматься и сейчас. Поэтому, если вам понравилась сама статья или начинания в популяризации Эликсира в рунете, пожалуйста, поддержите статью плюсами, комментариями и репостами. Это невероятно важно как для меня лично, так и для всего сообщества Эликсира в целом.
Другие статьи серии
Обо всех неточностях, ошибках, плохом переводе, пожалуйста, пишите личными сообщениями, буду оперативно исправлять. Заранее благодарю всех участвующих.