Мой блог про IT, ML и прочее

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

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

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

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

Многие современные API сужествуют годами и вынуждены поддерживать обратную совместимость на протяжении десятков версий. Одна из самых известных библиотек для линейной алгебры и прочих математических вычислений - NumPy сужествует с 2005 года и с тех пор поддерживает постоянство в дизайне API.

Методы или функции, которые пишем в наших программах, очень часто имеют несколько логических частей. Например, в рамках одной функции, если нам нужно отправить сообщение на сервер, мы можем 1) проверить его доступность, затем 2) отправить сообщение, и потом 3) проверить что сообщение было доставлено. Но достаточно ли такой подход отвечает принципу единственной ответственности SRP?

Использование apply в питоновской библиотеке Pandas

Типичное преобразование данных при работе с Pandas зачастую выглядит следующим образом:

import pandas as pd

df = pd.DataFrame({
    'City': ['Moscow', 'Stavropol', 'Volgograd'],
    'Temperature (C)': [22, 28, 18]
})

def celsius_to_fahrenheit(c):
    return (c * 9/5) + 32

df['Temperature (F)'] = df['Temperature (C)'].apply(celsius_to_fahrenheit)

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

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

Шутка про то, что программисты не всё-таки 100% времени проводят отлаживая код (иногда они еще создают новые баги) родилась совсем не на пустом месте. Значительную часть времени разработчики проводят, пытаясь отловить и исправить всевозможные ошибки в зачастую сложных и запутанных системах.

Простые и сложные решения

В мире программирования каждое техническое решение — это баланс между удобством сейчас и возможностями в будущем. Это особенно очевидно на примере двух систем кодирования символов: ASCII и Unicode. Их сравнение ярко демонстрирует, как выбор между текущим удобством и будущими возможностями может влиять на разработку программного обеспечения и обработку данных.