(3/5) Фреймворки и библиотеки
Какие популярные фреймворки или библиотеки существуют в разных областях разработки, таких как веб, мобильная разработка, машинное обучение и другие?

Существует множество популярных фреймворков и библиотек в разных областях разработки. Вот несколько примеров:

1. Веб-разработка:

- Django: фреймворк для разработки веб-приложений на языке Python.
- Ruby on Rails: фреймворк для разработки веб-приложений на языке Ruby.
- React: JavaScript-библиотека для создания пользовательских интерфейсов.
- Angular: фреймворк JavaScript для разработки одностраничных приложений.

2. Мобильная разработка:

- React Native: фреймворк для разработки мобильных приложений на базе React.
- Flutter: фреймворк для создания кросс-платформенных мобильных приложений на языке Dart.
- Xamarin: платформа для разработки кросс-платформенных мобильных приложений.

3. Машинное обучение и искусственный интеллект:

- TensorFlow: библиотека машинного обучения с открытым исходным кодом, разработанная Google.
- PyTorch: библиотека машинного обучения с открытым исходным кодом, разработанная Facebook.
- scikit-learn: библиотека машинного обучения для Python, предоставляющая инструменты для классификации, регрессии, кластеризации и др.

4. Разработка игр:
- Godot: популярный фреймворк для разработки 2D и 3D игр.
- Unreal Engine: мощный инструмент для разработки компьютерных игр и визуализации.

Кроме этих примеров, существует еще множество других фреймворков и библиотек в каждой области разработки, и выбор зависит от конкретных потребностей и предпочтений разработчика.

(4/5) Фреймворки и библиотеки
Как влияют фреймворки и библиотеки на производительность и эффективность разработки программного обеспечения?

Фреймворки и библиотеки могут существенно повлиять на производительность и эффективность разработки программного обеспечения. Вот несколько способов, как они влияют:

1. Ускорение разработки: Фреймворки и библиотеки предоставляют готовые решения и функциональность, которые способствуют ускорению разработки. Они предоставляют набор инструментов, шаблонов и компонентов, которые помогают разработчикам создавать приложения быстрее, поскольку многие типовые задачи уже реализованы.

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

3. Улучшение качества кода: Фреймворки и библиотеки прошли тщательное тестирование и используют передовые методы разработки. Это помогает повысить качество кода, уменьшить количество ошибок и проблем, связанных с безопасностью и совместимостью.

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

5. Расширяемость и гибкость: Фреймворки и библиотеки могут предложить механизмы для расширения и настройки функциональности под конкретные потребности проекта. Благодаря этим возможностям, разработчики могут легко адаптировать инструменты под свои требования и дополнять их новыми функциями.

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

(5/5) Фреймворки и библиотеки
Как определить, когда целесообразно использовать готовый фреймворк или библиотеку, а когда целесообразно создать индивидуальное решение?

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

1. Требования проекта: Оцените требования вашего проекта по функциональности, производительности, масштабируемости и другим критериям. Если проект требует специфических функций, которые затруднительно реализовать с использованием готового решения, возможно, создание индивидуального решения будет более подходящим.

2. Ограничения по времени: Если у вас есть ограниченные сроки для выполнения проекта, использование готового фреймворка или библиотеки может сэкономить время и ускорить разработку. Создание индивидуального решения может потребовать больше времени на проектирование, разработку и тестирование.

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

#интеграция

Сегодня я дам ссылочки на другие интересные статьи

1) Какие бывают юрлица - https://t.me/+Jin_etwu-I9mYzJi


2) Делегирование - https://t.me/+6y_vVyLl7jhjYjVi


3) Почему важны естественные спутники планет - https://t.me/+OAwzK0mOoJw4MDg6


4) Как устроено ядро планеты - https://t.me/+BaDups8kqCA5ZDg6

Привет, я Вася, Python-разработчик с примерно четырьмя годами коммерческого опыта в разных областях, от приборостроения до финтеха. Как и многие здесь, я полон энтузиазма, постоянно пилю небольшие проекты, от веб-сервисов и ботов до программ под Linux и пакетов процедурной генерации.

В разработку я пришел из науки. Я с отличием закончил физфак МГУ, занимался ядерными процессами в звездах, писал сложные численные модели, в основном на C++. Некоторые из моих симуляций крутились на компе неделями, в течение которых рассчитывались миллионы лет звездной эволюции. Потом наши с физикой дорожки разошлись: хоть я и был на хорошем счету, много публиковался и даже преподавал, особых перспектив видно не было. Ну и по гражданской позиции были трения с руководством. К концу маги я решил, что в IT у меня больше возможностей, а интересных задач там тоже завались. Так я решил полностью посвятить себя коммерческой разработке.

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

Как и многие молодые разрабы, я страдаю от синдрома самозванца. Тем не менее у меня объективно есть экспертиза, как в разработке, так и в связанных с нею софт-скиллах. Я могу помочь новичкам с Python, SQL (очень много работаю с БД в последние два года), моим любимым Linux, некоторыми инструментами разработчика вроде git и Docker. Готов подсказать с личными проектами -- как развернуть и админить свой сервис, какую БД выбрать, как настроить CI/CD.

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

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

Со мной можно связаться в телеге: @kot_tolstij. Еще у меня есть кринж-канал. У него нет узкой специализации, там все мои интересы в кучу: разработка, НРИ, походы и много всего прочего. Сейчас я ищу работу на западном рынке и планирую писать в канал про мои успехи на этом поприще. Возможно, вам будет интересно.

——————

#python #проекты #web #боты #linux #наука #физфакМГУ #SQL #git #docker #рефлексия #отдых #карьера

(1/6) Простой CI CD для пет проекта
Введение

Давайте определимся с тем, что такое CI/CD и зачем он нужен. CI/CD - это практика разработки программного обеспечения, которая объединяет в себе непрерывную интеграцию (Continuous Integration) и непрерывное развертывание (Continuous Deployment). Это позволяет автоматизировать процесс сборки, тестирования и развертывания приложения. CI/CD позволяет ускорить процесс разработки, уменьшить количество ошибок и упростить процесс развертывания приложения. В этой статье мы рассмотрим, как настроить простой CI/CD для пет проекта с использованием GitHub Actions.

И так, что нам понадобится для настройки CI/CD:

- GitHub репозиторий с проектом
- Docker
- GitHub Actions
- VPS сервер для развертывания приложения (2 ГБ оперативной памяти будет достаточно)

Разбираться будем на работующем проекте, который можно найти по ссылке:
https://github.com/roll-over/landing

Можно обратить внимание на то, что в репозитории уже есть файлы Dockerfile и docker-compose.yml, что упростит настройку CI/CD.
Также, не смотря на простое название, там уже несколько сервисов, которые нужно развернуть, что позволит нам познакомиться с различными ситуациями и даст возможность попрактиковаться в разборе говнокода.

(2/6) Простой CI CD для пет проекта
docker-compose.yml

Не будем тратить время на разбор проекта, а сразу перейдем к файлу docker-compose.yml, который описывает сервисы, которые нужно развернуть. В данном случае это landing_roll_over, minio и другие, на которые мы пока не будем обращать внимания.

---
landing_mongo:
  image: mongo
  container_name: landing_mongo
  restart: unless-stopped
  env_file:
    - .env
  volumes:
    - "./data:/data/db"
---
landing_roll_over:
  build: ./landing
  container_name: landing_roll_over
  working_dir: /frontend
  command: node build
  restart: unless-stopped
  ports:
    - "3011:3000"
  env_file:
    - .env
  depends_on:
    - landing_mongo
  environment:
    - DEV_MODE=false
---
minio:
  image: quay.io/minio/minio
  container_name: minio
  command: server /data --console-address ":9900"
  restart: unless-stopped
  ports:
    - "127.0.0.1:9900:9900"
    - "127.0.0.1:9001:9001"
  volumes:
    - "./minio_data:/data"
  environment:
    - MINIO_ROOT_USER=your_username
    - MINIO_ROOT_PASSWORD=your_pasword
    - MINIO_DEFAULT_BUCKETS=femida,landing,denta

Давайте немного разберемся с этим файлом. (Я рассчитываю на то что вы уже знакомы с Docker и Docker Compose, если нет, то рекомендую ознакомиться с этими технологиями, так как они очень удобны и позволяют упростить развертывание приложений.)

В данном файле описаны 3 сервиса: landing_mongo, landing_roll_over и minio.

Там и там мы указываем имя контейнера, который будет создан при развертывании сервиса. Также мы указываем порты, которые будут проброшены из контейнера на хост. В случае с landing_roll_over это порт 3011, в случае с minio это порты 9900 и 9001, а для монги мы вообще не указываем порт (что говорит о том что контейнер будет доступен только внутри виртуальной сети docker-compose). Также мы указываем, что сервисы должны перезапускаться в случае ошибки.
Есть еще ряд переменных, которые мы указываем для сервиса minio.

Обратите внимание на то, что в сервисе landing_roll_over мы указываем, что он зависит от сервиса landing_mongo. Это означает, что перед тем как запустить сервис landing_roll_over, нужно дождаться пока сервис landing_mongo будет запущен и готов к работе.

Так же стоит отметить, что в сервисе minio мы указываем, что контейнер будет доступен только на localhost, что означает, что он будет доступен только на сервере, на котором мы его развернем.

(3/6) Простой CI CD для пет проекта
Dockerfile

Теперь давайте разберемся с файлом Dockerfile, который описывает, как собрать образ для сервиса landing_roll_over.
Он лежит в папке landing, которая находится в корне проекта.

FROM node:20.5-slim AS base

COPY ./ /frontend
WORKDIR /frontend

RUN corepack enable
RUN pnpm install
ARG DEV_MODE=false
ARG ME_CONFIG_MONGODB_URL='mongodb://mongo:27017'
ARG OPENAI_API_KEY=''
ARG GOOGLE_ID=''
ARG GOOGLE_SECRET=''
RUN pnpm run build

В данном файле мы указываем, что образ будет создан на основе образа node:20.5-slim. Далее мы копируем все файлы из корня проекта в папку /frontend внутри образа. Далее мы указываем рабочую директорию /frontend и запускаем команды для установки зависимостей и сборки проекта.

Также мы указываем несколько переменных, которые будут доступны внутри образа. Это переменные DEV_MODE, ME_CONFIG_MONGODB_URL, OPENAI_API_KEY, GOOGLE_ID, GOOGLE_SECRET. Они будут доступны внутри образа и будут использованы при сборке проекта.

(4/6) Простой CI CD для пет проекта
Настройка сервера

Теперь давайте разберемся с настройкой сервера. Для развертывания приложения нам понадобится VPS сервер. Я рекомендую использовать сервер на базе Ubuntu 20.04, но сам использую debian 13. На сервере нам понадобится установить Docker и Docker Compose. (Тут я не буду останавливаться на установке Docker и Docker Compose, так как это можно найти в интернете.)

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

И под конец, нам нужно создать ssh ключи на сервере и добавить их в настройки репозитория на GitHub. Это нужно для того, чтобы GitHub Actions могли подключиться к серверу и выполнить команды для развертывания приложения.

Генерация ssh ключей и добавление их в авторизованные:

ssh-keygen -t rsa -b 4096
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

Копируем содержимое файла ~/.ssh/id_rsa и добавляем его в настройки репозитория на GitHub. Это нужно для того, чтобы GitHub Actions могли подключиться к серверу и выполнить команды для развертывания приложения.

(5/6) Простой CI CD для пет проекта
GitHub Actions

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

Давайте откроем файл .github/workflows/main.yml в корне проекта и увидем в нем следующий код:

name: "Deploy dev"

on:
  push:
    branches:
      - main
  workflow_dispatch:

env:
  # Setting an environment variable with the value of a configuration variable
  env_var: ${{ vars.ENV_CONTEXT_VAR }}

jobs:

---
run_pull:
    name: run pull
    runs-on: ubuntu-latest
    needs:
---
    steps:
    - name: install ssh keys
        # check this thread to understand why its needed:
        # https://stackoverflow.com/a/70447517
        run: |
        install -m 600 -D /dev/null ~/.ssh/id_rsa
        echo "${{ secrets.DEV_SSH_PRIVATE_KEY }}" > ~/.ssh/id_rsa
        ssh-keyscan -H ${{ vars.DEV_SSH_HOST }} > ~/.ssh/known_hosts
    - name: connect and pull
        run: ssh ${{ vars.DEV_SSH_USER }}@${{ vars.DEV_SSH_HOST }} "cd ${{ vars.DEV_DIR }} && git stash && git checkout ${{ vars.DEV_BRANCH }} && git pull"

    - name: stop containers -- 0 pack
        if: needs.landing_filter.outputs.output1 == 'true'
        run: ssh ${{ vars.DEV_SSH_USER }}@${{ vars.DEV_SSH_HOST }} "cd ${{ vars.DEV_DIR }} && docker-compose down landing_roll_over"
    - name: build and run containers -- 0 pack
        if: needs.landing_filter.outputs.output1 == 'true'
        run: ssh ${{ vars.DEV_SSH_USER }}@${{ vars.DEV_SSH_HOST }} "cd ${{ vars.DEV_DIR }} && docker-compose up -d --build landing_roll_over"
    ..

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

Ну, а теперь к steps. Это шаги, которые нужно выполнить при различных событиях. В данном случае мы указываем, что нужно выполнить шаги при пуше в ветку main и при ручном запуске workflow_dispatch.
Весь пайплайн будет проходить на linux версии ubuntu_latest


Шаг номер один и два - это установка ssh ключей и выполнение команды git pull на сервере. Это нужно для того, чтобы получить последние изменения из репозитория на сервере.

Шаг номер 3 и 4 - это остановка и запуск контейнера landing_roll_over. Это нужно для того, чтобы обновить контейнер до последней версии.

(6/6) Простой CI CD для пет проекта
Заключение
Этот метод легок и расширяем, но имеет ряд недостатков:
- Нет возможности быстро откатиться к предыдущей версии приложения в случае ошибки, только если ручками переключать ветку на сервере.
- Весь код на сервере хранится в репозитории, что может быть не безопасно.
- Старые контейнеры докера потихоньку отжирают место на сервере, их нужно удалять ручками.

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

----------------
Ставьте реакции, это поможет мне понять, что вам интересно и что нужно улучшить.

Если вам понравилась статья, то поделитесь ей с друзьями, это поможет мне развиваться и писать еще больше интересных статей.
Ссылка для того чтобы поделиться статьей: https://t.me/+bhtDL1JNSGM2YTMy

Вышло слишком длинно для tg, поэтому приложу еще и ссылочку на сайт, на котором таже статья, но в более удобном формате
https://dev.orby-tech.space/prostoi-ci-cd-dlia-piet-proiekta/

Вышла новая история одного разработчика!

https://t.me/story_of_one_developer

Принёс вам очень недооценный доклад про AWS для фронта

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

https://youtu.be/9GQmPlcf8Fc?si=lvm3OvKv5ZGkpXxY

P.S. Статья будет, но чуть позже=)

(1/4) Простейшая дубликация при деплое пет-проекта
Что такое дубликация и зачем она нужна при деплое пет-проекта?

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

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

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

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

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

(2/4) Простейшая дубликация при деплое пет-проекта
Классификация нод

В зависимости от того, какие задачи они выполняют, ноды могут быть разделены на несколько типов:

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

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

(3/4) Простейшая дубликация при деплое пет-проекта
Как реализовать простейшую дубликацию при деплое пет-проекта?

Тут я буду использвать все тот же репозиторий с моим пет-проектом, который я использовал в предыдущей статье.
https://github.com/roll-over/landing

Сразу долго не думая залетаем в репозиторий и смотрим файлик docker-compose.yml. Вот интересная нам часть:

services:
  cosmo_roll_over:
    build: ./cosmo
    container_name: cosmo_roll_over
    working_dir: /frontend
    command: node build
    restart: unless-stopped
    ports:
      - "3001:3000"
    env_file:
      - .env
    depends_on:
      - landing_mongo
    environment:
      - DEV_MODE=false
  cosmo_roll_over_1:
    build: ./cosmo
    container_name: cosmo_roll_over_1
    working_dir: /frontend
    command: node build
    restart: unless-stopped
    ports:
      - "3002:3000"
    env_file:
      - .env
    depends_on:
      - landing_mongo
    environment:
      - DEV_MODE=false

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

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

(4/4) Простейшая дубликация при деплое пет-проекта
Как реализовать балансировку нагрузки между нодами?

Для балансировки нагрузки между нодами, я буду использовать nginx. Вот часть конфигурации, которую я буду использовать:

Тут я создаю upstream, в котором я перечисляю все ноды, которые я хочу балансировать. В данном случае, у меня есть две ноды, которые слушают на портах 3001 и 3002.

upstream cosmo {
    ip_hash;
    server 104.248.21.81:3001;
    server 104.248.21.81:3002;
}

Далее, я создаю location, в котором я указываю, что все запросы, которые приходят на порт 80, должны быть перенаправлены на upstream cosmo.

server {
    listen 80;
    server_name cosmo.roll-over.dev;
    location / {
        proxy_pass http://cosmo;
    }
}

Естественно, это только часть конфигурации, и в реальной жизни, тут могут быть другие настройки, такие как ssl, gzip, rate limiting, http2, и т.д.

---

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


----------------
Ставьте реакции, это поможет мне понять, что вам интересно и что нужно улучшить.

Если вам понравилась статья, то поделитесь ей с друзьями, это поможет мне развиваться и писать еще больше интересных статей.
Ссылка для того чтобы поделиться статьей: https://t.me/+bhtDL1JNSGM2YTMy