Ошибки при изучении Python или 5 стадий принятия неизбежного

“Ученье – свет, а неученье – тьма”. Все мы слышали эту пословицу. Но никто не предупреждал, что путь ученья бывает тернист и что очень легко допустить ошибку. И чтобы вы не допускали ошибок в будущем, мы разобрали 5 ошибок при изучении Python.

✍️ Первая и самая простая ошибка – начинать изучение Python с чужого кода, а не с терминологии и концепции языка программирования.

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

✍️ Вторая - отказ от поиска и сравнения разных инструментов для оптимального решения задач.

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

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

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

✍️ Четвертая - делать скрипт нечитаемым, пренебрегая структурой.

Старайтесь во время написания кода внимательно относиться к новым переменным, подписывайте зачем они нужны, убирайте лишний блоки. Важно структурировать свой код. Позже для оформления кода можно использовать PEP 8 – руководство по стилю кода Python. Можете использовать для анализа инструменты, например, pycodestyle, prospector и пр. Не забудьте о пользовательских функциях.

✍️ Пятая ошибка - не сохранять удачные решения в базу знаний.

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

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

АНТИсоветы начинающим разработчикам

❗️Сначала изучить ВСЮ спецификацию языка, а потом учиться писать код
Если хотите качественный продукт, то делайте все сами от UX/UI дизайна до тестов. Все сами!
❗️ Код 24/7 – никогда не останавливайтесь и не отдыхайте. Забудьте о друзьях, семье. Только так придет успех, деньги, слава.
❗️ Никогда не пишите комментарии к коду. Там же итак все понятно и очевидно.
❗️Один стек наработали и хватит. Не изучайте ничего нового.
❗️Разработчики никогда не ошибаются. Все должно работать с первого раза, иначе меняйте профессию. Не созданы вы для этого.
❗️Тру разработчик не использует готовых решений и инструментов. Все пишет вручную. Все эти библиотеки, шаблоны, фреймворки – плагиат.
❗️Git для слабаков. Весь процесс разработки должен быть в голове. Мерджи, пуши, коммиты – зачем тратить лишние ресурсы.
❗️Дайте себе свободу. Захотели написать весь код в одну строчку – почему нет? Все эти методологии, ограничения, соглашения только мешают вам.

Но это все, конечно, шутки. 😆 Но не стесняйтесь добавить и свои вредные советы из личного опыта в комментариях. Явно у вас были свои забавные случаи, которые создали ваш личный "кодекс правил" в программировании. ⬇️

Кибирд снова с вами, и на этот раз в новом формате!

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

🔗 https://youtu.be/gVzl3H4-Oww

Приятного просмотра 😎

React vs. Vue

React и Vue являются двумя из самых популярных JavaScript-фреймворков, используемых для разработки веб-приложений. Мы не раз становились свидетелями баталий, в которых разработчики спорили о том, какой же фреймворк лучше. Но спорить в этом вопросе бесполезно! Хотя они оба используют JavaScript, они имеют ряд существенных различий, которые могут влиять на выбор разработчиков между ними:

⚙️ Архитектура

React использует виртуальную DOM (Document Object Model) для обновления пользовательского интерфейса, в то время как Vue использует синтаксис на основе шаблонов. Виртуальный DOM в React позволяет быстрее обновлять интерфейс, но может быть более сложным для понимания. Синтаксис Vue, основанный на шаблонах, проще в освоении, но может быть не таким производительным, как виртуальный DOM React.

🔎 Работа с данными

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

🔗 Компоненты

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

📚 Обучение

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

👥 Сообщества

React является более старым и высоко узнаваемым фреймворком. Он был создан компанией Facebook и используется в многих известных проектах, таких как Instagram и WhatsApp. Сообщество React очень активно и включает в себя много крупных компаний и ведущих разработчиков. Vue же является более молодым фреймворком, который приобрел популярность за последние несколько лет. Однако, у Vue открытый исходный код и активное и поддерживаемое сообщество разработчиков, которое стремится к развитию и улучшению фреймворка.

Итого, React - хороший выбор для больших и более сложных приложений, в то время как Vue - для небольших и более простых приложений. Выбор между React и Vue зависит от конкретных потребностей и предпочтений команды разработчиков. А с каким из этих фреймворков работаете вы?

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

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

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

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

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

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

🤳 Поддержка
Соглашения об уровне обслуживания (SLA) обеспечивают более персонализированную и индивидуальную поддержку частных облаков. Публичные облака, с другой стороны, обычно предлагают более общие услуги поддержки.

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

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

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

О чем не стоит забывать при переносе приложения в Kubernetes

Пост для тех, кто пишет код с нуля и планирует запустить его в Kubernetes, и для тех, у кого уже есть готовое приложение, которое нужно мигрировать в k8s.

📌Делайте выбор в пользу Stateless-приложений

Перезапуск и отключение нод – это норма для Kubernetes, особенно при автохилинге. Стоит организовать приложение так, чтобы данные писались в базы данных, файлы в S3 хранилище, а кэш в Redis, например. В общем, никакие данные, требующие сохранения, не должны писаться в контейнер, в котором приложение запущено. Так вы облегчаете масштабирование кластера под нагрузкой, когда нужно добавить доп ноды и репликацию.

📌 Не забывайте о Endpoints для проверки состояний приложений

В Kubernetes endpoints очень важны для отслеживания состояния приложения. Liveness помогает определить, когда пришло время перезапустить контейнер, а Readiness probes нужен для того, чтобы понять, когда контейнер готов принимать трафик.

📌SIGTERM обеспечивает graceful shutdown контейнера

Иногда Kubernetesм убивает приложение до того, как оно успевает освободить ресурсы. Как ответить на входящие запросы, не принимая новые, завершить транзакцию или сохранить данные в базу данных? Для этого есть SIGTERM. При завершении работы контейнера в его PID 1 прилетает сначала сигнал SIGTERM, затем приложению дается немного времени на корректное завершение.

📌Приложение не должно зависеть от того, на какой из подов приходит запрос

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

📌Не мучайтесь с SSL-сертификатами Kubernetes

Можно использовать отдельный сервис в оркестраторе — cert-manager, который можно просто доустановить. А еще есть Ingress Controller, который позволяет использовать SSL-сертификаты для терминации TLS-трафика. Можно применять как Let's Encrypt, так и заранее выпущенные сертификаты.

📌Приложение за реверс-прокси, соответственно, ссылки в HTTPS

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

Не так давно мы проводили HR Day. 😎🤘🏻

Событие прошло очень насыщенно и ярко, было много инсайдерской информации из первых уст и дискуссий по ним. Мы помним, что обещали поделиться презентациями наших сотрудников. Обещали, делаем! ⬇️

Ловите:

📌 «Держите одеяло у себя: как общаться с кандидатом и узнавать все, что вам интересно» — Маргарита Мысина, рекрутер в Mad Devs

📌«Дружелюбный онбординг: как с увеличением количества не потерять качество» — Клара Абдулова, HR-специалист в Mad Devs

А вам, кстати, удалось поучаствовать? Поделитесь впечатлениями в комментариях!

Зачем автоматизировать тесты в Agile-среде?

Ручное тестирование по прежнему необходимо в ряде случаев. Однако хорошая автоматизация все же помогает сильно сэкономить время и улучшить качество кода 🦾 Это становится критичным, если вы ведете Agile разработку, о чем сегодня мы и поговорим:

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

📌 Ручное регрессионное тестирование может привести к техническому долгу. Обычно Agile-команды запускают регрессионные тесты каждый день. Делая это вручную может потребовать помощи программистов, что в свою очередь влечет за собой потерю фокуса и увеличение технического долга. Автоматизация тестирования здесь, можно сказать, откровенно напрашивается и отлично решает проблему.

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

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

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

📌 Автоматические регрессионные тесты как подстраховка. Они предоставляют команде уверенность при изменении кода и помогают быстро обнаруживать дефекты, что особенно важно в гибкой разработке. Хороший охват автоматическими регрессионными тестами создает надежную среду для команды, позволяя им безопасно писать и добавлять код в основную ветку.

📌 Ручное тестирование подвержено человеческим ошибкам. С повторением одних и тех же задач, тестировщики могут начать упускать очевидные ошибки. Автоматизированные тесты могут быть запущены множество раз без изменений или ошибок. Такие тесты гарантируют, что процессы будут выполнены корректно, и улучшают согласованность работы команды. Это особенно важно в гибкой разработке, где быстрое выполнение тестов и обнаружение ошибок помогает команде быстро адаптироваться к изменениям и достичь лучших результатов.

Конечно, автоматическое тестирование не заменяет ручное, а лишь дополняет его, позволяя стандартизировать и ускорить процесс. ❤️

Если вы знаете больше преимуществ, которыми хотите поделиться, то ждем вас в комментариях. ⬇️

Хотите сделать проект на великом и могучем С++, но не уверены какой графической библиотекой пользоваться? Давайте разберемся! 🤟

📌 SFML это библиотека написана на C++ и предоставляет простой, быстрый и кроссплатформенный набор инструментов для разработки игр и мультимедиа. Она предлагает различные модули для работы с графикой, аудио, сетью и т.д., что делает ее универсальным решением для многих проектов. Она также предоставляет простой и интуитивно понятный API, что облегчает работу даже начинающим программистам.

📌 Qt это кросс-платформенная среда, которая предоставляет набор API для создания приложений, работающих на различных платформах, включая Windows, macOS, Linux и мобильные устройства. Qt предоставляет обширную библиотеку для разработки графического интерфейса, а также библиотеки для работы с сетями, мультимедиа и многое другое. Она также предоставляет интегрированную среду разработки (IDE) под названием Qt Creator, а также вам доступны QtDesigner, QDevelop, Edyuk, и интеграция с Visual Studio, Eclipse и XCode.

📌 Cairo - это библиотека векторной 2D-графики, которая обеспечивает высококачественный рендеринг векторной графики и изображений. Она широко используется в настольных, веб и мобильных приложениях и поддерживает широкий спектр устройств вывода, включая мониторы, принтеры и прочее. Cairo написана на языке C и предоставляет простой, низкоуровневый API, который облегчает разработчикам интеграцию векторной графики в свои приложения.

📌 Cocos2D-X - это кроссплатформенная игровая библиотека, предоставляющий набор инструментов и API для разработки 2D-игр. Она написана на C++ и обладает высокой степенью кастомизации, что позволяет разработчикам создавать игры, которые выглядят и ощущаются уникально. Cocos2D-X также предоставляет мощный и простой в использовании физический движок, что делает его отличным выбором для игр с достаточно сложной механикой.

📌 Juce - это кроссплатформенный фреймворк, который предоставляет набор API для создания мультимедийных приложений. Он написан на C++ и призван облегчить разработчикам создание приложений, работающих на различных платформах, включая Windows, macOS, Linux и мобильные устройства. Juce предоставляет полный набор библиотек для разработки графического интерфейса, обработки звука и отлично подходит для написания аудио плагинов.

📌 wxWidgets - это кроссплатформенный фреймворк для создания графического интерфейса, который использует низкоуровневый код и предоставляет набор API для создания приложений с нативным внешним видом на различных платформах, включая Windows, macOS, Linux и мобильные устройства. Он предоставляет не только полный набор библиотек для разработки графического интерфейса, но также и библиотеки для работы с сетью, мультимедиа, и различными устройствами ввода вывода.

📌 SDL 2.0 - SDL (Simple DirectMedia Layer) - это простая и быстрая кроссплатформенная мультимедийная библиотека для разработки игр и других мультимедийных приложений. Она предоставляет основные компоненты, такие как аудио, видео, системы ввода, а также поддержку различных аудио и видео форматов. SDL поддерживается на различных платформах, включая Windows, macOS, Linux и мобильные устройства, а также совместима с различными IDE, такими как Visual Studio, Code::Blocks и Xcode.

📌 GTK+ - это открытый многоплатформенный набор инструментов для создания графических пользовательских интерфейсов. Он предоставляет ряд функций, таких как управление окнами, обработка событий и управление макетом, а также поддерживает и несколько других языков программирования, включая чистый C. GTK+ широко используется для создания настольных приложений и является базовым инструментарием для популярной среды рабочего стола GNOME. Он поддерживается на различных платформах, включая Windows, macOS и Linux, и совместим с различными IDE, такими как Visual Studio, Code::Blocks и Eclipse.

Надеемся, теперь вам будет намного проще выбрать подходящую библиотеку ❤️

Как вы можете обесценить проектные ритуалы🤔

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

📌 Кик-офф — это установочная встреча участников проекта, на которой обозначают цели проекта, определяют основные роли в команде и обсуждают, как будет выстроена работа.

Что точно поможет?
— Пригласите деливери или сейлз менеджеров, чтобы подробно описать команде требования заказчика.
— При появлении нового члена команды – проведите новый кик-офф.
— Не пропускайте онбординг новых членов команды. Полезно будет создать страницу в confluence с чеклистом для онбординга, чтобы ничего не забыть.

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

Что точно поможет?
— Чтобы не затягивать встречи, фиксируйте проблемы и обсуждайте в рамках рабочих встреч, где будут только причастные.
— Если вы менеджер - не забывайте, что вы член команды, а не начальник. Ваш дейлик не должен состоять из одних созвонов.
— Напомните, что "сделал" не равно "делал". Так как "делал" не говорит о чем-то конкретном. Для ПМ-а должно быть "красным флагом", если сотрудник уже несколько дней делает таску.
— Активность и живость членов команды во время встречи зависит от ПМ-а. Склеивайте встречу, добавляйте переходы, задавайте вопросы, комментируйте.

📌 Ретроспектива — это один из ритуалов, который прямо влияет на качество проекта и процессов в нём. Цель — увеличить эффективность работы команды через улучшение процессов и рефлексию.

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

📌 One-on-one (1:1) — это регулярные встречи с простыми правилами, во время которых легко раскрыться.

Что точно поможет?
— Не опаздывайте на встречи и будьте включенными в разговор.
— Отложите все гаджеты в сторону.
— Не обесценивайте проблемы собеседника. Постарайтесь помочь в поиске решений.
— Откажитесь от панибратства.

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

🧠 Давайте поговорим про ИИ.

Кроме ChatGPT, существуют и другие сервисы. Собрали 5 развлекательных веб-приложений с ИИ, за которыми вы можете скоротать вечер.

Quick, Draw!
Игра предлагает вам нарисовать объект или идею, а нейросеть пытается угадать, что вы изобразили. Хитрость в том, что разработчики обучили алгоритм следить за движением курсора/пальца.

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

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

Система построена с использованием библиотеки TensorFlow.

Scroobly
Оживите придуманного персонажа. Система использует Facemesh и PoseNet, чтобы скоординировать движения человека и персонажа в режиме реального времени.

Для машинного обучения использовали библиотеки TensorFlow.js, а для анимации компьютерной 3D-графики Three.js.

Semantris
Выберете тетрис или аркаду и сыграйте в слова. Основа сервиса – технология семантического поиска.

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

В аркадном режиме вам нужно подобрать близкие по смыслу слова, на которые указывает ИИ.

AI Dungeon
Это многопользовательская текстовая приключенческая игра, в которой ИИ генерирует контент. А при желании можно и в синглплеер.

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

В начале игры у вас есть 4 основных метода взаимодействия: Do, Say, Story и See.
Дальше система адаптируется и реагирует на большинство примененных пользователем действий, а пустое поле побуждает ИИ к генерации нового контента.

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

🎮 Может, у вас есть свои фавориты? Расскажите в комментариях.

Пришло время размяться. У нас для вас новая задачка 🧠

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

Вопрос:
Сколько денег у вас было изначально и сколько концертов вы посетили?

Решения этой задачи мы опубликуем завтра, а пока ждем ваши варианты в комментариях 👇

Итак, решение:

Начнем с последнего концерта:
После посещения первого благотворительного концерта (1) у вас осталось $0, следовательно, у вас было (0+100)/2 = 50$ перед посещением концерта.

Перед посещением второго концерта (2) у вас было (50+100)/2 = 75.

Перед посещением третьего концерта (3) у вас было (75+100)/2 = 87,5.

Перед посещением четвертого концерта (4) у вас было (87,5+100)/2 = 93,75.

Перед посещением пятого концерта (5) у вас было (93,75+100)/2 = 96,875, что превышает исходные условия. Приходим к выводу, что мы посетили 4 концерта.

Поздравляем, вы великолепны! ✨ Вы отлично провели время, посетили 4 концерта, а вас у вас карманцах было $93.75.

Ну что, кто решал так же?