(2/4) Введение в облака
Какие основные провайдеры облачных сервисов существуют?

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

1. Amazon Web Services (AWS)
2. Microsoft Azure
3. Google Cloud Platform (GCP)
4. IBM Cloud
5. Oracle Cloud

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

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

(3/4) Введение в облака
Каковы основные особенности использования облачных технологий?

Преимущества использования облачных технологий:

1. Гибкость и масштабируемость. (Вы можете арендовать ресурсы на время, когда они вам нужны, и при этом дополнительные ресурсы могут быть предоставлены автоматичемски, если нагрузка на сайт возрастет)
2. Автоматическое обновление программного обеспечения. (Вам не нужно заботиться о том, чтобы обновить программное обеспечение, так как это делает провайдер)

А в случае петпроекта, например, можно использовать бесплатные облачные сервисы, такие как GitHub Pages, Netlify, Vercel или тот же AWS

Не стоит забывать и о недостатках:

1. Зависимость от провайдера облачных сервисов. (Vendor lock-in, единыжды написанный код может быть сложно перенести на другой сервис)
2. Безопасность данных. (Вам придется особенно заботиться о безопасности данных, так как они будут храниться не у вас, а у провайдера)

(4/4) Введение в облака
Какие основные сервисы предоставляют облачные провайдеры?

Основные сервисы, которые предоставляют облачные провайдеры:

1. Вычислительные мощности (виртуальные машины, контейнеры, серверы)
2. Хранение данных (базы данных, файловое хранилище)
3. Сетевые сервисы (балансировка нагрузки, DNS, CDN)
4. Инструменты разработки (CI/CD, мониторинг, логирование)

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

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


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

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

* Введение в облака

Решил немного добавить про облака и почему они для петпроекта очень хорошее решение, особенно если нет опыта с серверами

1) Вам не нужно париться за настройки — у нормальных облачных систем хороший графический интерфейс
2) Ваша статическая страница будет грузиться гораздо быстрее чем с сервера за счёт того что сервера подбираются ближе к пользователю
3) Вы естественно познакомитесь с технологиями, которыми можно флексить в резюме



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

(1/5) S3 для самых маленьких
Введение

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

(2/5) S3 для самых маленьких
Что такое бакет?

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

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

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

Мне кажется самая удобная аналогия для понимания S3 - это Google Drive. Только вместо папок и файлов у вас будут бакеты и объекты.

(3/5) S3 для самых маленьких
Настройка демо для фронтенда на S3

1. Для начала нам нужно создать бакет. Для этого переходим в консоль S3 и нажимаем на кнопку "Создать бакет". (S3 Можно найти по поиску по сервисам)

2. Далее вводим имя бакета и выбираем регион. Все остальные настройки оставляем по умолчанию.

3. После создания бакета в нем появится вкладка "Объекты". Нажимаем на нее и затем на кнопку "Загрузить".

4. Выбираем файл, который хотим загрузить в бакет. В моем случае я подготовил простенький index.html, который я и загружу. https://github.com/orby-tech/s3-example

5. Теперь давайте займемся доступами. Мы можем видеть таб со свойствами ("Properties"), в котором откроем блок "Хостинг статического веб-сайта" ("Static website hosting"). Включим его и введем имя файла индекса. В моем случае это index.html.

6. Нажимаем "Сохранить" и теперь у нас есть доступ к нашему файлу по адресу, который указан в поле "Конечная точка". У меня это - http://s3-example.s3-website.eu-north-1.amazonaws.com/

7. Но, что же мы видим? 403! Это потому что у нас нет прав на просмотр файла. Давайте это исправим.

8. Переходим во вкладку "Разрешения" ("Permissions") и находим блок "Блокировка публичного доступа" ("Block public access (bucket settings)"). Отключаем все блокировки и нажимаем "Сохранить". (Пока не будем говорить о том, хорошо это или плохо)

9. И там же в "Разрешениях" ("Permissions") находим блок "Владелец объекта" ("Object Ownership") и выбираем ACLs enabeld. Нажимаем "Сохранить".

10. Возваращаемся в бакет, находим кнопку "Действия" и выбираем "Cделать публичным используя ACL" ("Make public using ACL"). Нажимаем "Сохранить".

11. Теперь мы можем посмотреть наш сайт по адресу, который мы видели ранее. Ура! Мы создали бакет, загрузили в него файл и настроили доступ к нему.

(4/5) S3 для самых маленьких
А что еще интересного можно сделать с бакетами?

1. Естественно, S3 создан для работы с ним из сервисов или лямбд. В случае сервисов, я начал работать с бакетами в Minio, который я установил на своем сервере. В случае лямбд, можно создать функцию, которая будет обрабатывать файлы в бакете. Например, сжимать изображения или конвертировать их в другой формат.

2. Можно настроить жизненный цикл объектов. Например, если файл не используется более 30 дней, то он будет перенесен в холодное хранилище, где его хранение будет дешевле.

3. Можно настроить версионирование. Если вам важно сохранить историю изменений файлов, то вы можете включить версионирование и восстанавливать предыдущие версии файлов.

4. Ну и мы видим, что у нашей ссылки на сайт нет SSL. Можно настроить CloudFront, который будет работать с S3 и предоставлять SSL. А еще и будет иметь симпатичный домен. (Этим займемся в следующих статьях)

(5/5) S3 для самых маленьких
Заключение

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


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

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

Я затянул с публикацией постов и прошу меня извинить, но у меня для вас накопилось нечто интересное. Хочу поделиться накопленным опытом и пониманием роли AQA (Automated Quality Assurance) за время работы над долгосрочным проектом.

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

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

3. Разнообразие методов автоматизации:
- Не стоит считать, что один вид автоматизации лучше другого. Все они имеют свои сильные и слабые стороны. E2E тесты охватывают весь пользовательский процесс, но медлительны и требовательны к ресурсам. Юнит-тесты быстры и охватывают большой объем кода, но не покрывают взаимодействия компонентов. API тесты отлично проверяют бэкэнд, но не всю систему в целом. Только сочетая все эти подходы, можно достичь максимального покрытия и уверенности в качестве продукта.

4. Адаптация существующих процессов:
- Если на проекте хорошо выстроено ручное тестирование, автоматизация пройдет быстрее и чётче. Однако, потребуется время на перевод тестов в автоматизацию и создание соответствия между ручными и автоматизированными тестами, возможно, разработка собственных инструментов.

5. Работа с командой:
- Команда может быть не готова к автоматизации и, возможно, ей потребуется обучение. Это необходимо для демонстрации преимуществ и вовлечения команды в процесс автоматизации.

6. Почему Java популярна для AQA:
- Популярность Java объясняется структурой кода — java с первых строк заставляет писать в виде классов, а это очень хорошо ложится на e2e тестирование, потому что ты можешь сделать "цифровую" копию приложения и работать через компактные абстракции.

Это сильно уменьшает количество кода и сильно его же упрощает.

7. Регулярный рефакторинг:
- Не стоит забывать про рефакторинг автотестов — это важно для поддержания их актуальности и пользы.

8. Ранняя интеграция:
- Не откладывайте интеграцию автотестов в процесс разработки. Чем раньше, тем лучше. Начать стоит как только проект стабилизируется, даже если не с первого коммита.

9. Интеграция с CI/CD:
- Важна своевременная интеграция автотестов в CI/CD, что сэкономит время на адаптацию.

10. Мониторинг:
- Мониторинг автотестов так же важен, как мониторинг самого приложения. Алерты, например, через вебхуки, могут быть полезны на начальных этапах.

11. "Дикий запад" автоматизации:
- Автоматизация тестирования до сих пор поднимает много вопросов в компании — это не редкость. Возможно, вам придется внедрять свои решения и объяснять их ценность.

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

13. Классификация тестов:
- Разбивайте автотесты на группы по типу и скорости для оптимизации процесса тестирования.

14. Фича-флаги:
- Интегрируйте фича-флаги в автотесты, чтобы эффективно управлять функциями и багами, которые не фиксятся сразу.

Эти мысли только начало обсуждения, и я могу вернуться к этой теме в будущем. Большое спасибо всем, кто прочитал этот пост и поддержал меня в этом проекте.

Спасибо за внимание, удачи вам в автоматизации тестирования!

Сейчас мне не нужна работа, но что, если понадобится?

Примерно с такими мыслями я начал новый петпроект/тулзу (кодом делиться не буду, убежден, что в этом случае сильно важнее концепт).

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

Сам бот состоит из 3 частей:

1. Получение вакансий
Это может быть и телеграм-канал(ы) (telegram-api, где вы можете заходить как юзер, а не бот), так и сайты вакансий (playwright).

2. Фильтрация и форматирование
Фильтрацию можно начать просто по ключевым словам, но если подключить почти любую LLMку, то и по более сложным паттернам, таким как локация/опыт/зп/наличие прямого контакта.
На данный момент я использую o3-mini, она мне показалась самой подходящей, следом идет 3.5turbo.
Модельку я прошу сформировать JSON, и при должной аккуратности в промте модельки выдают его валидным.

Могу только посоветовать не брать дорогие модели, под эти цели я не увидел необходимости тратить больше денях.

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

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

Естественно, можно идти дальше и сделать автоотклик, но оно нужно не всем (мне приятнее откликаться самому).

P.S. контакты я замазал, т.к. лень думать о легальности публикации оных, но могу уверять, это полноценные ссылки mailto и контакты тг.

Как я по своей глупости чуть не потерял все свои архивные фото

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

Хочу поделиться тем, как я чуть не потерял 11 497 файлов, большинство из которых были фото и видео — по большому счёту семейный архив.

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

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

Забегая вперёд, скажу, что по итогу потеряно 0 файлов, а дальше расскажу, что, на мой взгляд, помогло это сделать.

Что делал:

Из-за того что жидкость солёная, я первым делом разобрал твердотельный накопитель и убедился, что жидкость попала на плату. Она была залита серьёзно, и жидкость уже сильно испарилась, и я решился помыть её под водой (сейчас я бы поступил чуть иначе — помыл бы либо в дистилляте или спирте, но тогда не было под рукой, а действовать нужно было быстро).

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

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

Было написано два скрипта:
1. Смотрит в ресурс и в директорию, в которую она переносится, делает полный пересчёт всех файлов, которые надо перенести, и сохраняет статус по каждому файлу в JSON.
2. Идёт по списку и поочередно(!) копирует каждый файл.

Тем самым нагрузка на жёсткий диск упала, и во временные промежутки я смог копировать по более чем 1000 файлов, а протокол "не трогать папочки" + json-ка со статусами дала возможность убедиться, что скопировано всё.

В итоге накопитель дал скачать всё, но затянулось это почти на месяц: конкретно мой диск иногда впадал во временную защиту — его можно было перезапустить, а иногда впадал в долгую(?) защиту, и приходилось ждать по 3–4 дня до следующего включения.
Честно говоря, я не до конца понимаю, как эти защиты устроены, но кажется, ОС диска записывает это куда-то и проверяет при запуске. Проверить это возможности нет, но по поведению очень похоже. Я бы, наверное, так и делал, если бы разрабатывал жёсткие диски.

Что можно было бы ещё сделать, чтобы смягчить удар по истории:
1. Скачать историю чатов, из которых фоточки могли бы взяться (естественно, докинуть ещё и старые бэкапы, если есть), и пройтись по структуре сорса + сверить по размеру файла, тем самым восстановить хоть и не утерянные, но неструктурированные данные.
2. Греть феном плату перед подключением — кажется, это помогает ему запуститься (это я где-то прочитал, что таким образом восстанавливают некоторые SSD).
3. Найти спецов, которые занимаются этим профессионально (я даже не искал — нет уверенности, что они не сделают ещё хуже, и всё-таки приватные данные, делиться с третьими лицами не всегда хочется).
4. Была идея, что защита держится на заряженных конденсаторах, и можно было бы класть плату на фольгу между запусками (так делают с материнскими платами, чтобы сбросить настройки BIOS, но с накопителем так поступить я испугался).

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

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

(Если интересно, могу рассказать про систему хранения в следующей статье, но обещаю: там нет rocket science.)