Изучаем 😊

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

Если у Вас есть знакомые, кому это интересно, кто хочет начать заниматься, делитесь с ними 👩‍❤️‍👨.

Как войти в айти (часть 2)👋?

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

Психологические барьеры на пути в IT

😅Синдром самозванца 😅

Первое, с чем сталкивается практически каждый новичок — ощущение, что ты не достоин находиться в IT. "Я недостаточно умный", "У меня нет математического склада ума", "Я гуманитарий" и тп.
Правда в том, что абсолютно все разработчики когда-то не знали, как написать даже простейшую программу. И даже сейчас, с опытом в 10+ лет, они регулярно гуглят базовые вещи и испытывают неуверенность. Это нормально!

😅Информационная перегрузка 😅

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

😅Ожидание мгновенных результатов 😅

В эпоху TikTok и Instagram мы привыкли к мгновенным дофаминовым всплескам. Программирование же — это марафон, а не спринт. Первые недели или даже месяцы могут быть особенно трудными, когда ты много вкладываешь, но видимого прогресса мало.

Продолжим в следующем посте под данным тегом 👋

Всех с праздниками👩‍❤️‍👨

Изучаем 😊

Ваш покорный хакер трудится для Вас даже в выходные...

Цените это, дорогие подписчики 😇

Изучаем 😇

Я похож на абонента?❔
Да, сегодня разберем операторы.

Подписывайтесь, чтобы не пропустить полезное 🦈

Программа для подписчиков 👋

Круто, что вы заходите на мой канал, ставите реакции и участвуете в опросе. Я это очень ценю 👍
Поэтому, когда Вас станет здесь больше…100, например, я напишу кому-нибудь из Вас программу по Вашему желанию. Или помогу разобраться с Вашим проектом, если Вы начинающий в этой сфере.
Думаю, это будет классно.
Всем удачи ❤️🐱

Добрый вечер, друзья!👋

Хочу уделить пару минут тому, как сделать ваши Python-скрипты чуть более шустрыми и надёжными перед тем, как отправиться отдыхать. Рассмотрим джентльменкий набор профилирования и оптимизации кода.

Почему профилирование важно?😵‍💫

Часто узкое место программы не там, где вы ожидаете. Вместо долгих угадок воспользуйтесь профилировщиком:
🥺Вы увидите, какие функции отнимают наибольшее время.
🐱Сможете обоснованно перераспределить усилия.
🐱Избежите преждевременной оптимизации вслепую.

Инструменты профилирования в стандартной библиотеке 😏

😇cProfile: простой и информативный профайлер:

python -m cProfile -s cumulative my_noscript.py

- s cumulative — сортировка по суммарному времени выполнения.
Следовательно, вывод покажет, сколько раз вызывалась каждая функция и сколько времени она заняла.

🥳 pstats: для интерактивного анализа результатов:

import pstats 
p = pstats.Stats('profile.out')
p.strip_dirs().sort_stats('cumulative').print_stats(10)

strip_dirs() убирает лишние пути из имён модулей.
print_stats(10) — показывает топ-10 «тягучек».

🍄 Пример:

1) Кодим:

import time 

def slow_function(n): 
    total = 0 
    for i in range(n): 
        total += i ** 2 
    return total 

def main(): 
    start = time.time()    print(slow_function(1_000_000)) 
    print('Elapsed:', time.time() - start) 

if __name__ == '__main__': 
    main()

2) Профилируем:

python -m cProfile -o profile.out example.py

import pstats
p = pstats.Stats('profile.out') p.sort_stats('cumulative').print_stats(5)

Вы увидите, что slow_function явно «тормозит».

🌟Где взять speed?

1) Использовать встроенные функции вместо ручного цикла:

total = sum(i*i for i in range(n))

это часто быстрее за счёт C-реализации sum.

2) NumPy для численных расчётов Если у вас большие векторы:

import numpy as np arr = np.arange(n) total = np.dot(arr, arr)

— в десятки раз быстрее чистого Python.

3) Мемоизация Для функций с повторяющимися вызовами:

from functools import lru_cache 

@lru_cache(maxsize=None) 

def fib(n): 
    if n < 2: 
        return n 
    return fib(n-1) + fib(n-2)

4) Асинхронность и многопоточность Подойдут для I/O-bound задач:

import asyncio 

async def fetch_data(): 

 # имитируем запрос 

    await asyncio.sleep(1) 
    return 'data' 

async def main(): 
    results = await asyncio.gather(*(fetch_data() for _ in range(5))) 
    print(results) 
asyncio.run(main())

❤️Что по итогу?

Не гонитесь за микрооптимизациями 😏: начните с измерений, выявите узкие места и примените подходящий инструмент.
На этом всё! Желаю продуктивного кода и спокойного вечера. 😉

Github быть или не быть 😑

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

Однако существуют серьезные риски (киски 😋).

Проблемы безопасности — один из ключевых аспектов. Известны случаи внедрения вредоносного кода в популярные библиотеки, как произошло с пакетом event-stream в экосистеме Node.js, когда злоумышленники добавили функционал для сбора данных криптовалютных кошельков пользователей (да, история давно минувших дней, но мне все равно https://snyk.io/blog/malicious-code-found-in-npm-package-event-stream/). Тысячи проектов оказались под угрозой до обнаружения проблемы.

Лицензирование представляет другую проблему. Разница между лицензиями MIT, Apache и GPL может иметь критическое значение для проекта. Например, GPL требует открытия исходного кода всего проекта при использовании библиотеки под этой лицензией, что может противоречить коммерческим интересам. Неосведомленность в вопросах лицензирования потенциально ведет к юридическим последствиям.

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

Для минимизации рисков рекомендуется следовать проверенным практикам. 🐱

Анализируйте репутацию проекта: активность разработки, количество решенных проблем, качество документации. Проводите анализ кода перед интеграцией и тестируйте решение в условиях, приближенных к продакшну. Используйте инструменты мониторинга уязвимостей, такие как Dependabot, Snyk или npm audit.
Использование открытого кода требует взвешенного подхода. Преимущества в виде экономии времени и доступа к экспертным решениям должны оцениваться в контексте потенциальных рисков для безопасности, технической стабильности и юридических аспектов проекта. Осознанное применение открытого кода становится важным профессиональным навыком современного разработчика.

Добиваем Github 🐾

Думаю, надо раскрыть кое-какие моменты из предыдущего поста ❔

💃 MIT лицензия – одна из самых либеральных. Ты можешь делать с кодом практически всё: модифицировать, распространять, использовать в коммерческих проектах. Единственное требование – указать автора оригинального кода и включить текст лицензии в свой проект.
💃 Apache License 2.0 – похожа на MIT, но добавляет защиту от патентных исков. Если ты используешь код под этой лицензией и имеешь патенты, связанные с этим кодом, ты автоматически предоставляешь бесплатную лицензию на эти патенты другим пользователям кода.
💃 GNU General Public License (GPL) – "вирусная" лицензия. Если ты используешь код под GPL в своем проекте, ты обязан выпустить весь проект также под GPL и предоставить его исходный код. Это может быть проблематично для коммерческих продуктов, где исходный код – жеская тайна.
💃 LGPL (Lesser GPL) – смягченная версия GPL. Позволяет использовать библиотеку в закрытом проекте без необходимости открывать весь код, но модификации самой библиотеки должны распространяться под LGPL.

В общем, если собрались использовать код с GitHuba в своем стартапе, то убедитесь, что библиотеки под MIT или Apache.

😛 Dependabot интегрирован прямо в GitHub. Он автоматически сканирует зависимости Вашего проекта, проверяя их на наличие известных уязвимостей. Когда находит проблему, создает pull-request с обновлением уязвимой библиотеки до безопасной версии.
🐱 Snyk – более продвинутый инструмент. Он не только находит уязвимости в зависимостях, но и сканирует твой собственный код на предмет безопасности, может блокировать деплой, если находит критические уязвимости. Работает через анализ абстрактного синтаксического дерева (AST) кода и сравнение паттернов с известными уязвимостями.
😊 npm audit / yarn audit – встроенные в пакетные менеджеры JavaScript инструменты. При установке зависимостей они автоматически проверяют их на уязвимости. Технически они отправляют список зависимостей и их версий в централизованную базу данных уязвимостей и получают отчет о проблемах.

Посыл: лучше всегда проверить активность библиотеки, изучить документацию, с самого начала позаботиться о Dependabot или Snyk и о подписке на канал🤪.

👍Помните, большая сила - большая ответственность.