Горячее
Лучшее
Свежее
Подписки
Сообщества
Блоги
Эксперты
Войти
Забыли пароль?
или продолжите с
Создать аккаунт
Я хочу получать рассылки с лучшими постами за неделю
или
Восстановление пароля
Восстановление пароля
Получить код в Telegram
Войти с Яндекс ID Войти через VK ID
Создавая аккаунт, я соглашаюсь с правилами Пикабу и даю согласие на обработку персональных данных.
ПромокодыРаботаКурсыРекламаИгрыПополнение Steam

Топ прошлой недели

  • Oskanov Oskanov 8 постов
  • alekseyJHL alekseyJHL 6 постов
  • XpyMy XpyMy 1 пост
Посмотреть весь топ

Лучшие посты недели

Рассылка Пикабу: отправляем самые рейтинговые материалы за 7 дней 🔥

Нажимая кнопку «Подписаться на рассылку», я соглашаюсь с Правилами Пикабу и даю согласие на обработку персональных данных.

Спасибо, что подписались!
Пожалуйста, проверьте почту 😊

Новости Пикабу Помощь Кодекс Пикабу Реклама О компании
Команда Пикабу Награды Контакты О проекте Зал славы
Промокоды Скидки Работа Курсы Блоги
Купоны Biggeek Купоны AliExpress Купоны М.Видео Купоны YandexTravel Купоны Lamoda
Мобильное приложение

Golang

С этим тегом используют

Программирование IT Программист Разработка Все
82 поста сначала свежее
55
noopel
noopel
3 года назад
Лига программистов

Разработка системы заметок с нуля. Часть 2: REST API для RESTful API Service + JWT + Swagger⁠⁠

Продолжаем серию материалов про создание системы заметок. В этой части мы спроектируем и разработаем RESTful API Service на Go cо Swagger и авторизацией. Будет много кода, ещё больше рефакторинга и даже немного интеграционных тестов.

В первой части мы спроектировали систему и посмотрели, какие сервисы требуются для построения микросервисной архитектуры.


Исходники проекта — в репозитории на GitHub.


Подробности в видео и текстовой расшифровке под ним.

Прототипирование


Начнём с макетов интерфейса. Нам нужно понять, какие ручки будут у нашего API и какой состав данных он должен отдавать. Макеты мы будем делать, чтобы понять, какие сущности, поля и эндпоинты нам нужны. Используем для этого онлайн-сервис NinjaMock. Он подходит, если макет надо сделать быстро и без лишних действий.

Страницу регистрации сделаем простую, с четырьмя полями: Name, Email, Password и Repeat Password. Лейблы делать не будем, обойдемся плейсходерами. Авторизацию сделаем по юзернейму и паролю.

После входа в приложение пользователь увидит список заметок, который будет выглядеть примерно так:

Разработка системы заметок с нуля. Часть 2: REST API для RESTful API Service + JWT + Swagger API, Программирование, Golang, Python, Mockup, Rest, Видео, Длиннопост

Интерфейс, который будет у нашего веб-приложения:

- Слева — список категорий любой вложенности.

- Справа — список заметок в виде карточек, который делится на два списка: прикреплённые и обычные карточки.

- Каждая карточка состоит из заголовка, который урезается, если он очень длинный.

- Справа указано, сколько секунд/минут/часов/дней назад была создана заметка.

- Тело заголовка — отрендеренный Markdown.

- Панель инструментов. Через неё можно изменить цвет, прикрепить или удалить заметку.


Тут важно отметить, что файлы заметки мы не отображаем и не будем запрашивать у API для списка заметок.


Полная карточка открывается по клику на заметку. Тут можно сразу отобразить полностью длинный заголовок. Высота заметки зависит от количества текста. Для файлов появляется отдельная секция. Мы их будем получать отдельным асинхронным запросом, который не помешает пользователю редактировать заметку. Файлы можно скачать по ссылке, также есть отдельная кнопка на добавление файлов.

Разработка системы заметок с нуля. Часть 2: REST API для RESTful API Service + JWT + Swagger API, Программирование, Golang, Python, Mockup, Rest, Видео, Длиннопост

Так будет выглядеть открытая заметка


В ходе прототипирования стало понятно, что в первой части мы забыли добавить еще один микросервис — TagsService. Он будет управлять тегами.


Определение эндпоинтов


Для страниц авторизации и регистрации нам нужны эндпоинты аутентификации и регистрации соответственно. В качестве аутентификации и сессий пользователя мы будем использовать JWT. Что это такое и как работает, разберём чуть позднее. Пока просто запомните эти 3 буквы.

Для страницы списка заметок нам нужны эндпоинты /api/categories для получения древовидного списка категорий и /api/notes?category_id=? для получения списка заметок текущей категории. Перемещаясь по другим категориям, мы будем отдельно запрашивать заметки для выбранной категории, а на фронтенде сделаем кэш на клиенте. В ходе работы с заметками нам нужно уметь создавать новую категорию. Это будет метод POST на URL /api/categories. Также мы будем создавать новый тег при помощи метода POST на URL /api/tags.

Разработка системы заметок с нуля. Часть 2: REST API для RESTful API Service + JWT + Swagger API, Программирование, Golang, Python, Mockup, Rest, Видео, Длиннопост

Чтобы обновить заметку, используем метод PATCH на URL /api/notes/:uuid с измененными полями. Делаем PATCH, а не PUT, потому что PUT требует отправки всех полей сущности по спецификации HTTP, а PATCH как раз нужен для частичного обновления. Для отображения заметки нам ещё нужен эндпоинт /api/notes/:uuid/files с методами POST и GET. Также нам нужно скачивать файл, поэтому сделаем метод GET на URL /api/files/:uuid.

Разработка системы заметок с нуля. Часть 2: REST API для RESTful API Service + JWT + Swagger API, Программирование, Golang, Python, Mockup, Rest, Видео, Длиннопост

Структура репозитория системы


Ещё немного общей информации. Структура репозитория всей системы будет выглядеть следующим образом:

Разработка системы заметок с нуля. Часть 2: REST API для RESTful API Service + JWT + Swagger API, Программирование, Golang, Python, Mockup, Rest, Видео, Длиннопост

В директории app будет исходный код сервиса (если он будет). На уровне с app будут другие директории других продуктов, которые используются с этим сервисом, например, MongoDB или ELK. Продукты, которые будут использоваться на уровне всей системы, например, Consul, будут в отдельных директориях на уровне с сервисами.


Разработка сервиса


Писать будем на Go


- Идём на официальный сайт.

- Копируем ссылку до архива, скачиваем, проверяем хеш-сумму.

- Распаковываем и добавляем в переменную PATH путь до бинарников Go

- Пишем небольшой тест проверки работоспособности, собираем бинарник и запускаем.


Установка завершена, всё работает


Теперь создаём проект. Структура стандартная:

- build — для сборок,

- cmd — точка входа в приложение,

- internal — внутренняя бизнес-логика приложения,

- pkg — для кода, который можно переиспользовать из проекта в проект.


Я очень люблю логировать ход работы приложения, поэтому перенесу свою обёртку над логером logrus из другого проекта. Основная функция здесь Init, которая создает логер, папку logs и в ней файл all.log со всеми логами. Кроме файла логи будут выводиться в STDOUT. Также в пакете реализована поддержка логирования в разные файлы с разным уровнем логирования, но в текущем проекте мы это использовать не будем.


APIService будет работать на сокете. Создаём роутер, затем файл с сокетом и начинаем его слушать. Также мы хотим перехватывать от системы сигналы завершения работы. Например, если кто-то пошлёт приложению сигнал SIGHUP, приложение должно корректно завершиться, закрыв все текущие соединения и сессии. Хотел перехватывать все сигналы, но линтер предупреждает, что os.Kill и SIGSTOP перехватить не получится, поэтому их удаляем из этого списка.


Теперь давайте добавим сразу стандартный handler для метрик. Я его копирую в директорию pkg, далее добавляю в роутер. Все последующие роутеры будем добавлять так же.

Далее создаём точку входа в приложение. В директории cmd создаём директорию main, а в ней — файл app.go. В нём мы создаём функцию main, в которой инициализируем и создаём логер. Роутер создаём через ключевое слово defer, чтобы метод Init у роутера вызвался только тогда, когда завершится функция main. Таким образом можно выполнять очистку ресурсов, закрытие контекстов и отложенный запуск методов. Запускаем, проверяем логи и сокет, всё работает.

Но для разработки нам нужно запускать приложение на порту, а не на сокете. Поэтому давайте добавим запуск приложения на порту в наш роутер. Определять, как запускать приложение, мы будем с помощью конфига.


Создадим для приложения контекст. Сделаем его синглтоном при помощи механизма sync.Once. Пока что в нём будет только конфиг. Контекст в виде синглтона создаю исключительно в учебных целях, впоследствии он будет выпилен. В большинстве случаев синглтоны — необходимое зло, в нашем проекте они не нужны. Далее создаём конфиг. Это будет YAML-файл, который мы будем парсить в структуру.


В роутере мы вытаскиваем из контекста конфиг и на основании listen.type либо создаем сокет, либо вешаем приложение на порт. Код graceful shutdown выделяем в отдельный пакет и передаём на вход список сигналов и список интерфейсов io.Close, которые надо закрывать. Запускаем приложение и проверяем наш эндпоинт heartbeat. Всё работает. Давайте и конфиг сделаем синглтоном через механизм sync.Once, чтобы потом безболезненно удалить контекст, который создавался в учебных целях.


Теперь переходим к API. Создаём эндпоинты, полученные при анализе прототипов интерфейса. Тут важно отметить, что у нас все данные привязаны к пользователю. На первый взгляд, все ручки должны начинаться с пользователя и его идентификатора /api/users/:uuid. Но у нас будет авторизация, иначе любой пользователь сможет программно запросить заметки любого другого пользователя. Авторизацию можно сделать следующим образом: Basic Auth, Digest Auth, JSON Web Token, сессии и OAuth2. У всех способов есть свои плюсы и минусы. Для этого проекта мы возьмём JSON Web Token.


Работа с JSON Web Token


JSON Web Token (JWT) — это JSON-объект, который определён в открытом стандарте RFC 7519. Он считается одним из безопасных способов передачи информации между двумя участниками. Для его создания необходимо определить заголовок (header) с общей информацией по токену, полезные данные (payload), такие как id пользователя, его роль и т.д., а также подписи (signature).


JWT использует преимущества подхода цифровой подписи JWS (Signature) и кодирования JWE (Encrypting). Подпись не даёт кому-то подделать токен без информации о секретном ключе, а кодирование защищает от прочтения данных третьими лицами. Давайте разберёмся, как они могут нам помочь для аутентификации и авторизации пользователя.


Аутентификация — процедура проверки подлинности. Мы проверяем, есть ли пользователь с полученной связкой логин-пароль в нашей системе.


Авторизация — предоставление пользователю прав на выполнение определённых действий, а также процесс проверки (подтверждения) данных прав при попытке выполнения этих действий.

Другими словами, аутентификация проверяет легальность пользователя. Пользователь становится авторизированным, если может выполнять разрешённые действия.


Важно понимать, что использование JWT не скрывает и не маскирует данные автоматически. Причина использования JWT — проверка, что отправленные данные были действительно отправлены авторизованным источником. Данные внутри JWT закодированы и подписаны, но не зашифрованы. Цель кодирования данных — преобразование структуры. Подписанные данные позволяют получателю данных проверить аутентификацию источника данных.


Реализация JWT в нашем APIService:

- Создаём директории middleware и jwt, а также файл jwt.go.

- Описываем кастомные UserClaims и сам middlware.

- Получаем заголовок Authorization, оттуда берём токен.

- Берём секрет из конфига.

- Создаём верификатор HMAC.

- Парсим и проверяем токен.

- Анмаршалим полученные данные в модель UserClaims.

- Проверяем, что токен валидный на текущий момент.


При любой ошибке отдаём ответ с кодом 401 Unauthorized. Если ошибок не было, в контекст сохраняем ID пользователя в параметр user_id, чтобы во всех хендлерах его можно было получить. Теперь надо этот токен сгенерировать. Это будет делать хендлер авторизации с методом POST и эндпоинтом /api/auth. Он получает входные данные в виде полей username и password, которые мы описываем отдельной структурой user. Здесь также будет взаимодействие с UserService, нам надо там искать пользователя по полученным данным. Если такой пользователь есть, то создаём для него UserClaims, в которых указываем все нужные для нас данные. Определяем время жизни токена при помощи переменной ExpiresAt — берём текущее время и добавляем 15 секунд. Билдим токен и отдаём в виде JSON в параметре token. Клиента к UserService у нас пока нет, поэтому делаем заглушку.


Добавим в хендлер с heartbeat еще один тестовый хендлер, чтобы проверить работу аутентификации. Пишем небольшой тест. Для этого используем инструмент sketch, встроенный в IDE. Делаем POST-запрос на /api/auth, получаем токен и подставляем его в следующий запрос. Получаем ответ от эндпоинта /api/heartbeat, по истечении 5 секунд мы начнём получать ошибку с кодом 401 Unauthorized.


Наш токен действителен очень ограниченное время. Сейчас это 15 секунд, а будет минут 30. Но этого всё равно мало. Когда токен протухнет, пользователю необходимо будет заново авторизовываться в системе. Это сделано для того, чтобы защитить пользовательские данные. Если злоумышленник украдет токен авторизации, который будет действовать очень большой промежуток времени или вообще бессрочно, то это будет провал.


Чтобы этого избежать, прикрутим refresh-токен. Он позволит пересоздать основной токен доступа без запроса данных авторизации пользователя. Такие токены живут очень долго или вообще бессрочно. После того как только старый JWT истекает мы больше не можем обратиться к API. Тогда отправляем refresh-токен. Нам приходит новая пара токена доступа и refresh-токена.

Хранить refresh-токены на сервере мы будем в кэше. В качестве реализации возьмём FreeCache. Я использую свою обёртку над кэшем из другого проекта, которая позволяет заменить реализацию FreeCache на любую другую, так как отдает интерфейс Repository с методами, которые никак не связаны с библиотекой.


Пока рассуждал про кэш, решил зарефакторить существующий код, чтобы было удобней прокидывать объекты без dependency injection и синглтонов. Обернул хендлеры и роутер в структуры. В хендлерах сделал интерфейс с методом Register, которые регистрируют его в роутере. Все объекты теперь инициализируются в main, весь роутер переехал в мейн. Старт приложения выделили в отдельную функцию также в main-файле. Теперь, если хендлеру нужен какой-то объект, я его просто буду добавлять в конструктор структуры хендлера, а инициализировать в main. Плюс появилась возможность прокидывать всем хендлерам свой логер. Это будет удобно когда надо будет добавлять поле trace_id от Zipkin в строчку лога.

Вернемся к refresh_token. Теперь при создании токена доступа создадим refresh_token и отдадим его вместе с основным. Сделаем обработку метода PUT для эндпоинта /api/auth, а в теле запроса будем ожидать параметр refresh_token, чтобы сгенерировать новую пару токена доступа и refresh-токена. Refresh-токен мы кладём в кэш в качестве ключа. Значением будет user_id, чтобы по нему можно было запросить данные пользователя у UserService и сгенерировать новый токен доступа. Refresh-токен одноразовый, поэтому сразу после получения токена из кэша удаляем его.


Описание API


Для описания нашего API будем использовать спецификацию OpenAPI 3.0 и Swagger — YAML-файл, который описывает все схемы данных и все эндпоинты. По нему очень легко ориентироваться, у него приятный интерфейс. Но описывать вручную всё очень муторно, поэтому лучше генерировать его кодом.


- Создаём эндпоинты /api/auth с методами POST и PUT для получения токена по юзернейму и паролю и по Refresh-токену соответственно.

- Добавляем схемы объектов Token и User.

- Создаём эндпоинты /api/users с методом POST для регистрации нового пользователя. Для него создаём схему CreateUser.


Понимаем, что забыли сделать хендлер для регистрации пользователя. Создаём метод Signup у хенлера Auth и структуру newUser со всеми полями для регистрации. Генерацию JWT выделяем в отдельный метод, чтобы можно было его вызывать как в Auth, так и в Signup-хендлерах. У нас всё еще нет UserService, поэтому проставляем TODO. Нам надо будет провалидировать полученные данные от пользователя и потом отправить их в UserService, чтобы он уже создал пользователя и ответил нам об успехе. Далее вызываем функцию создания пары токена доступа и refresh-токена и отдаём с кодом 201.


У нас есть подсказка в виде Swagger-файла. На его основе создаём все нужные хендлеры. Там, где вызов микросервисов, будем проставлять комментарий с TODO.


Создаём хендлер для категорий, определяем URL в константах. Далее создаём структуры. Опираемся на Swagger-файл, который создали ранее. Далее создаём сам хендлер и реализуем метод Register, который регистрирует его в роутере. Затем создаём методы с логикой работы и сразу пишем тест API на этот метод. Проверяем, находим ошибки в сваггере. Таким образом мы создаём все методы по работе с категориями: получение и создание.


Далее создаём таким же образом хендлер для заметок. Понимаем, что забыли методы частичного обновления и удаления как для заметок, так и для категорий. Дописываем их в Swagger и реализуем методы в коде. Также обязательно тестируем Swagger в онлайн-редакторе.

Здесь надо обратить внимание на то, что методы создания сущности возвращают код ответа 201 и заголовок Location, в котором находится URL для получения сущности. Оттуда можно вытащить идентификатор созданной сущности.


В третьей части мы познакомимся с графовой базой данных Neo4j, а также будем работать над микросервисами CategoryService и APIService.

Показать полностью 5
[моё] API Программирование Golang Python Mockup Rest Видео Длиннопост
4
61
noopel
noopel
3 года назад
Лига программистов

Разработка системы заметок с нуля. Часть 1: проектирование микросервисной архитектуры⁠⁠

Начинаем серию видео по разработке системы заметок на Python, Golang и микросервисной архитектуры. Будем писать код и конфигурировать все используемы инфраструктурные продукты, такие как ElasticSearch, logstash, Kibana, zipkin, mongoDB, postgresql. И все это в докер контейнерах и с использованием docker compose.

В этом видео мы уточним функционал и спроектируем систему, разберемся с основными микросервисами и продуктами. которые будем использовать.


Ссылка на GitHub репозиторий: https://github.com/theartofdevel/notes_system


Вопрос: нужна ли текстовая расшифровка для этой стать и для будущих?


P.S. первая статья, не знаю правильно все сделал, если нет - поправьте в комментариях - все исправлю.

P.P.S. еще есть плейлисты с уроками по Go и Python, а также еще разный контент. Буду сюда тоже постить потихоньку.

[моё] Golang Python Разработка Микросервисы Mongodb Видео
55
1.............16
1.............16
3 года назад

Странный сон⁠⁠

Вопрос знатокам, в соннике трактовку не отыскал.

В общем снилось мне, что программирую я на Go (вполне успешно), используя какие-то невнятные, но интуитивные библиотеки.

Воспринимать сон как вещщий?
К чему такое снится?
Это может быть воззванием силы и я на самом деле избранный?

P.S. Доходы у меня на уровне сеньёра го.
P.S.S. Хоть образование у меня и техническое, от программирования я далёк.

Странный сон Сон, Вопрос, Golang, Сила
Показать полностью 1
[моё] Сон Вопрос Golang Сила
7
23
wingblack
wingblack
3 года назад

Нетрадиционная... передача данных⁠⁠

Наверное, только человек который вроде как умеет программировать, но по каким-то причинам использующий его только в качестве эпизодического хобби, может позариться создать откровенную хрень, которая маловероятно чтобы она кому-то еще понадобится, и  он делает ее просто потому что может.


Так я где-то в своих старых постах, в рамках изучения языка С#, предъявил Пикабу свою поделку - программу которая "конвертирует" любой файл в видео состоящее из цветных или черно-белых квадратиков, которое можно залить на ютуб (перекодировать), скачать, и все еще иметь возможность извлечь исходные данные (почти всегда) без ошибок.

Какая идея то была - вот ютуб бесплатно хранит видео, считай бесплатный хостинг без лимита на один аккаунт. Почему бы туда еще и данные какие-нибудь хранить, файломопойку устроить. Офигеть классная идея, не правда ли?

Поделку можно считать условно удачной, т.к. с заявленной задумкой вполне справлялась, кроме пары моментов до которых руки особо не дошли, особенно с учетом что в дальнейшем особо никому, да и мне  тоже, она особо не понабилось.


А на днях я решил изучить язык Go (можно гуглить как Golang). Ну а поскольку учить нужно на практике... Да, снова взялся за ту же старую задумку, с учетом наработанного опыта по реализации старой идеи... ну почти...

На этот раз идея встала вокруг использования Twitch в качестве передачи данных онлайн. В принципе, можно использовать любую онлайн платформу для стриминга игр и прочего, лишь бы была возможность передавать видео не только через официальный клиент. Так, например, множество платформ принимают стрим по протоколу RTMP.

Ну и еще один очень важный момент - должна быть возможность скачивать стрим напрямую, в режиме онлайн. Так для Твича я использовал FFmpeg для стрима, и Youtube-dl + FFmpeg для скачивания трансляции.


На данном этапе программа еще не готова для публичного "потыкать" - к примеру командная строка не реализовна. На гитхаб репозиторий еще не делал но обязательно сделаю

В качестве теста работоспособности идеи я взял интернет радио в формате MP3 и его транслировал на Твич, записал прямой эфир и "конвертировал" обратно в MP3. Запись правда делал в ручном режиме, а потом конвертировал файл с видео, так как нужно было сначала просто проверить что так можно сделать, следующим шагом буду автоматизировать это.

Но хотя при прослушивании MP3 явных косяков не замечено, не исключено что не все так гладко, хоть Твич и позволяет смотреть исходный сигнал без перекодирования, что позволяет считать в кадрах видео ошибок не будет, но я предполагаю что какие-то кадры могут потеряться целиком (надеюсь что этого не будет).

Примерно так выглядит кадр из видео

Нетрадиционная... передача данных Golang, Программирование, Бред, Длиннопост

Да, ч/б квадратики - решение далеко не оригинальное, даже сказать (на данном этапе работы над программой) это и есть сырые данные без доп обработки. Но использование такого формата, как показал мой опыт над предыдущей программой, является более предпочтительным, в том числе из-за простоты конвертации. Ну и размер файла раздувается примерно одинаково при разных примененных способах формирования квадратов, раз в 10, а бывает даже больше (при учете что видео делается так чтобы была возможность обратного преобразования). А я пробовал и квадраты разных цветов, и даже выдирал кусок кода из енкодера x264, то что касается  DCT и IDCT - для формирования соответствующих квадратов.

С учетом что наиболее важен размер, и не столько важно количество формируемых кадров, выбор ч/б квадратов считаю вполне оправданным.

Тут даже можно картинку полупрозрачную поверх рисовать, в теории, надо проверять как это повлияет на все факторы.

Сделав прогу с ч/б квадратами можно потом переделать и под что-то другое, закончить бы сначала :)


Из минусов такого способа "передачи данных" можно назвать один явный (то что это вообще никому нифига не нужно - пропустим :) ) - это то что это передача данных в один конец. Это ж трансляция, на нее невозможно напрямую отвечать. Если кто-то захочет использовать эту хрень для двунаправленной передачи данных, то нужно запускать отдельный стрим для каждого из участников.

Другой минус - что передача и получение большого объема данных требует существенных вычислительных затрат (нагрузка CPU). Плюс, я уже говорил, нужна ширина канала примерно в 10 раз больше исходного потока данных.


P.S. Нет, это не имеет отношение к стеганографии, и да это очевидно заметная передача данных. Если, как предлагали уже многие, пытаться скрывать данные за каким-нибудь фильмом, то доступная плотность данных резко уменьшится при увеличении вычислительной сложности.

По поводу незаметного использования игро-стриминговых платформ для передачи данных очевидно напрашивается создать что-то похожее на игру, но чтобы можно было легко соотнести происходящее на экране с определенными сообщениями. К этому будет сложнее придраться, но опять же плотность данных падает, а вычислительная сложность (хотя бы для случая декодирования) сильно возрастает.

Проект не претендует на новизну и полезность, так - бред недопрограммиста.

Показать полностью 1
[моё] Golang Программирование Бред Длиннопост
20
232
DELETED
3 года назад
Лига Криптовалют

Нужен ли рассказ, как работают криптовалюты с точки зрения разработчика и кода?⁠⁠

Всем доброго дня.

Я какое-то время ошиваюсь на Пикабу. Иногда читаю про крипту и каждый раз удивляет уровень понимания, что это и зачем. Он почти отсутствует.

Я сам core developer Ethereum

Точнее я отработал в Status.im, затем в geth, основном клиенте Эфириума, после чего по гранту Ethereum Foundation с новой командой стали переделывать Эфир под более эффективную и быструю модель данных (сейчас наша полная архивная нода занимает чуть меньше 1Tb, и с нуля синхранизируется за 3-4 дня на NVMe SSD, против 9 Tb и месяца у go-ethereum (geth)).


К счастью разработка пока ещё легальна, в отличие от владения и использования крипты. Про разработку и работу Эфириума я и думал рассказать, как backend разработчик.


Сейчас же мне важно понять насколько это интересно народу тут, на Пикабу.


Жду вашего отклика.



Пруфы:

* Github https://github.com/JekaMas

* Пруф, что это я https://github.com/JekaMas/pikabu_ethereum_proof

* Ethereum https://github.com/ethereum/go-ethereum/blob/master/AUTHORS

* Erigon https://github.com/ledgerwatch/erigon#team

* Status.im https://github.com/status-im/status-go/graphs/contributors

* Резюме https://www.linkedin.com/in/eugene-danilenko-90895524

* Вроде всё

Показать полностью
[моё] Программирование Golang Ethereum Cryptocurrency Криптовалюта Криптография Текст
154
g9rga
4 года назад

Как я решил сделать мобильное приложение[Part 2]⁠⁠

1 часть


Исходный код парсера и остальных компонентов приложения положил под систему контроля версий git, в качестве бесплатного хостинга приватных репозиториев я использовал github. В принципе, ничего сложного в настройке нет, создал репозиторий на github и проинициализировал его локально:

Как я решил сделать мобильное приложение[Part 2] Программирование, Длиннопост, IT, Golang

После этого развернул локально базу данных mysql в локальном k8s-кластере с помощью minikube + helm(взял 3 версию, до этого использовал 2, из явных плюсов увидел только отсутствие tiller)+ чарт bitnami/mysql(конфигурацию чарта опущу, там все по-умолчанию):

Как я решил сделать мобильное приложение[Part 2] Программирование, Длиннопост, IT, Golang
Как я решил сделать мобильное приложение[Part 2] Программирование, Длиннопост, IT, Golang
Как я решил сделать мобильное приложение[Part 2] Программирование, Длиннопост, IT, Golang

Спроектировал структуру базы данных, получилась не очень красиво, из-за большой вариативности данных, но это можно переделать потом:

Как я решил сделать мобильное приложение[Part 2] Программирование, Длиннопост, IT, Golang
Как я решил сделать мобильное приложение[Part 2] Программирование, Длиннопост, IT, Golang

Пара заметок по структуре базы данных:

- таблица recipe_parser и некоторые вспомогательные поля нужны для сохранения прогресса парсинга сайта между перезапусками парсера

- выбрал кодировку utf8mb4, потому что в контенте достаточно много emoji, и обычный utf8(трехбайтовый) их не может хранить

За структуру проекта для парсера, я взял golang-standards/project-layout. В принципе для такого мелкого приложения его можно было не использовать, но может кому-то будет полезно знать что есть такая штука, когда будет думать как структурировать проект. Получилось как-то так:

Как я решил сделать мобильное приложение[Part 2] Программирование, Длиннопост, IT, Golang

Соответственно:

* recipe-parser - это helm-чарт который я создал выше

* sql - папка с миграциями
* data - это папка с данными базы данных, ее необходимо хранить на хосте, чтоб не потерять данные если мой локальный кластер случайно удалится

* все остальное - код связанный с парсингом, конфиги, команды

Для написания самого парсера я использовал следующие пакеты:

- PuerkitoBio/goquery - для парсинга DOM страниц

- jmoiron/sqlx - для работы с базой данных

- sirupsen/logrus - как логгер

- spf13/cobra - для создания команд

- spf13/viper - для конфигурации приложения(yaml в папке configs)

Сам код парсера не вижу смысла выкладывать(технически он несложный), получились такие этапы:

- спарсить категории/подкатегории и записать в базу

- спарсить ссылки рецептов и записать в базу

- скачать все страницы с рецептами и записать на диск(кстати получилось достаточно много, почти 9gb данных):

Как я решил сделать мобильное приложение[Part 2] Программирование, Длиннопост, IT, Golang

- считать с диска страницы, распарсить и записать в базу данных

Везде где можно, я параллелил задачи с помощью горутин и буферизированных каналов для контроля количества потоков. Также на сайте присутствовала защита от ботов, но я ее обошел за счет того, что она работала неправильно. В результате получил на выходе базу данных с ~500 категориями и ~90к готовых рецептов с заголовком, описанием, картинками и шагами приготовления. Еще было бы неплохо выкачать все картинки и закинуть в свое облако(использую space от digital ocean), но это пока можно отложить.

На написание парсера и сам парсинг я потратил примерно три вечера. Конечно все то что я описал можно было не делать, но те базы данных что продаются в интернете гораздо меньше и хуже структурированы чем то что я собрал сам, тем более я получил кучу полезного опыта в процессе. С радостью отвечу на ваши вопросы, некоторые моменты я опустил, чтоб пост не получился сильно большой.

В следующем посте собираюсь написать небольшой бекенд на php (и конечно засунуть все в docker :) , с которым будет работать мобильное приложение.

Показать полностью 7
[моё] Программирование Длиннопост IT Golang
11
77
jidckii
4 года назад
Лига слаботочников

Ещё 1 регистратор для видеонаблюдения⁠⁠

Хочу рассказать про видеорегистратор который мы с друзьями писали последние 2 года, почему мы это начали и куда движемся.

Ещё 1 регистратор для видеонаблюдения Cctv, Видеонаблюдение, Видеорегистратор, Golang, Vue, Программное обеспечение, Программирование, Безопасность, Юкка, Слаботочка, Видео, Длиннопост

Для тех кому лень читать и он хочет сразу потыкаться ссылка на сайт

Там есть ссылки на документацию с инструкциями как установить, а так же демо видео обзор возможностей.


Немного обо мне.

Я работаю инфраструктурным инженером, в быту DevOps. Начинал своё путешествие в мир IT из тех. поддержки интернет провайдера, затем работал в системным администратором на местном телеканале, в тот период очень активно изучал linux, писал скрипты на баше, в силу специфики предприятия(тв канал) познакомился с такой прекрасной утилитой, как ffmpeg. Я был поражён на сколько это крутой софт для работы с любым медиа контентом. Это можно считать точной отсчёта примерно 2016-год.


Путь к идее.

Примерно 2,5 года назад мой друг открыл магазин автозапчастей и встал вопрос организации видеонаблюдения. Хотелось что бы доступ к видео был с любого устройства, архив можно скачать любого промежутка, и естественно всё бесплатно. В общем то не очень много требований.

Так повелось, что все технические вопросы он задавал мне и я пошёл изучать этот рынок. Пошёл смотреть что там есть на алиэкспресс из готовых недорогих железок. Сначала обрадовался, железные решения были очень бюджетные, но поняв, что софт там на уровне 2003-го (а на дворе был уже 2017), обязательно нужен internet explorer и использование ActiveX вкладку с алиэкспресс я закрыл )

Начал гуглить что есть готового софтового, естественно первое что приходит на ум это zoneminder , нашёл даже сразу сборку в докере, запустил, открыл и .... полное разочарование.

Интерфейс всё так же напоминал 2003-год. Даже я разбирался как добавить камеру минут 10 и без документации не обошлось. Из плюсов безусловно то, что проект старый и стабильный, есть куча фишек связанных с детекцией движения и прочее, но пользоваться этим обычному пользователю не очень удобно, нужно что то интуитивное как ютуб.

Дальше я пробовал и ставил всё, что нагуглил, все решения, опенсорсные, проприетарные, любые.

В итоге из всего, что я попробовал мне понравилось 2 решения это Flussonic Watcher и shinobi.

Flussonic Watcher - NVR российской разработки, написан на erlang, работа с транспортом видео реализована самостоятельно. Это крутой софт! У флюсоника работа с архивом сделана так как я себе её и представлял в идеале, кто то уже сделал то, что я придумал себе в голове ) Но это платное решение при том достаточно дорогое, по этому от него я отказался. Но очень вдохновился.

Sinobi - это Open-Source проект, написан на nodejs, работа с транспортом видео реализована при помощи ffmpeg. Этот проект выглядел как что то, чем сможет пользоваться обычный человек. Но всё же интерфейс кажется слишком перегружен, да и стабильность работы в 2017-м оставляла желать лучшего. Я запарковал камеру оставил на 1 час, через час картинка просто зависла и в архив писался бесконечный стоп кадр. Про процесс добавления нового потока, я вообще молчу )


В итоге меня ничего не устроило, я просто написал несколько скриптов на баше, ffmpeg забирал с камеры поток в RTSP, добавил docker, посолил nginx и на выходе получил что то работающее. Запустил это на домашнем сервере(старый комп который стоит за холодильником), запустил и оно работало !  Кажется это можно считать прототипом нашего будущего видео регистратора и выглядело это вот: https://cam1.yuccastream.com/ https://github.com/yuccastream/cam1


Понеслась.

Я рассказал о своей идее сделать собственный видеорегистратор друзьям. Ребята приняли идею с энтузиазмом. Обсудили перспективы и возможности. Да и просто было интересно сделать что то своё и классное )  И мы начали работу.

Так как разработкой мы занимались в свободное время от основной работы, темпы были черепашьи.

Но время шло, код писался, и начало вырисовываться что то, что уже можно показывать людям.

Цель была почти та же, что и при запросе моего друга с автомагазином: "можно запарковать любую ip камеру, доступ к видео с любого устройства, архив можно скачать любого промежутка, и естественно всё бесплатно".

К определённому моменту мы поняли, что достигли этой цели и тут я хочу показать несколько демо как это выглядит.

Вот так выглядит добавление новой камеры:

Так как для транспорта мы используем ffmpeg, на входе может быть почти любой протокол.

Единственное ограничение, видео должно быть в кодеке h264, в этом кодеке пишут 100% всех современных ip камер, так что не очень то и ограничение.


Вот так выглядит работа с архивом:

Согласитесь интуитивно ? Почти как в ютубе )


Как установить к себе ?

Тут всё просто вам нужен любой современный linux, где можно запустить docker, или MacOS.

Есть сборки под Raspberry pi.

Возможно в будущем появится поддержка windows, но сейчас с этим проблемы.


Есть платная версия.

Yucca - это не открытое программное обеспечение (

К сожалению мы не придумали как зарабатывать на опенсорсе. Но есть чёткая позиция, что базовый функционал всегда должен быть бесплатным.

У есть 2 версии FREE и ENTRPRISE.

FREE - бесплатна и имеет весь необходимый функционал для организации видеонаблюдения в организации или дома.

ENTRPRISE - платная подписка, имеет функционал который может быть интересен большим компаниям или провайдерам услуги видеонаблюдение. Тут есть разграничение прав по пользователям, брендирование и список будет пополнятся.


Контакты

Сайт:  https://yucca.app/

У нас есть чатик у телеграме, если кто заинтересовался и есть вопросы, то вот ссылка.


P.S.: если где опечатка или лишняя запятая, пишите )

Показать полностью 1 2
[моё] Cctv Видеонаблюдение Видеорегистратор Golang Vue Программное обеспечение Программирование Безопасность Юкка Слаботочка Видео Длиннопост
37
1452
smokin.marlboro
5 лет назад
Лига программистов

Как избавиться от расизма в IT⁠⁠

Из https://www.opennet.ru/opennews/art.shtml?num=53109

В основную кодовую базу языка Go принято изменение, убирающее из исходных текстов и документации фразы whitelist/blacklist и master/slave, неприятие которых усилилось на фоне бушующих в США протестов. Фразы "whitelist" и "blacklist" заменены на "allowlist" и "blocklist", а "master" и "slave" в зависимости от контекста на "process", "pty", "proc" и "control".
Как избавиться от расизма в IT Golang, Программирование, Идиотизм, Политкорректность
Golang Программирование Идиотизм Политкорректность
222
Посты не найдены
О Нас
О Пикабу
Контакты
Реклама
Сообщить об ошибке
Сообщить о нарушении законодательства
Отзывы и предложения
Новости Пикабу
RSS
Информация
Помощь
Кодекс Пикабу
Награды
Команда Пикабу
Бан-лист
Конфиденциальность
Правила соцсети
О рекомендациях
Наши проекты
Блоги
Работа
Промокоды
Игры
Скидки
Курсы
Зал славы
Mobile
Мобильное приложение
Партнёры
Промокоды Biggeek
Промокоды Маркет Деливери
Промокоды Яндекс Путешествия
Промокоды М.Видео
Промокоды в Ленте Онлайн
Промокоды Тефаль
Промокоды Сбермаркет
Промокоды Спортмастер
Постила
Футбол сегодня
На информационном ресурсе Pikabu.ru применяются рекомендательные технологии