Техкофе

Дизайнеры свайпа на MagicMouse, выйдите со мной на связь. Зачем ставить по дефолту на одно и то же движение свайпа вправо и горизонтальную прокрутку текста и переход к предыдущей странице? Прокрутка превращается в возврат к предыдущей странице браузера, когда вы у границы текста. Без оттяжки, как при вертикальной прокрутке ленты, без люфта, без ничего. Просто возврат назад. Это убивает формы для ввода текста в браузере: один неосторожный спайп вправо, и вы закрываете без сохранения форму ввода, теряете все введенные данные. Даже этот пост я написал со второго раза. Первую версию удалил свайп вправо. Браво.

Взялся за изучение обзорной статьи по всем достижениям в области LLM: "Large Language Models: A Survey". Знания из статьи - отдельный рассказ. У этой статьи - более 200 ссылок на другие статьи с 1954 до 2023 года. Смотрю я на этот список и думаю: а что если взять вообще все статьи на arxiv и построить по ним PageRank или какой-то другой топ по цитированию. Потратив минут 5 на гугл, я не смог найти именно такой проект с графом цитирования. Потратив еще времени на поиск информации выяснил, что arxiv в своем апи доступа к данным о статьях скрывает данные о цитировании (что уже интересный и неочевидный факт). За то есть проект по парсингу цитирований из тестов статей здесь: huggingface.co/...set Вообще было бы интересно сделать pet-проект по графу цитирований

Как я веду документацию по задаче 3/3 Раздел "вопросы" (и ответы) жизненно нужен, когда по задаче приходится что-то уточнять: где лежат данные для обработки, что означает тот или иной код ошибки, какие тулзы использовать и тд. Заполняя этот раздел, вы сохраните большую картину процесса разработки и быстрее будете приходить к решению. Пример из жизни: многие спикеры и преподаватели во время своей лекции просят слушателей свои вопросы записывать и задавать их в конце. Чаще всего бывает, что мы сами отвечаем на свои вопросы со временем. Очень часто моя работа заключается в поиске рабочей комбинации настроек нескольких систем обработки данных. Ведение раздела с личными вопросами и ответами помогает составить мне работающий паззл из множества возможных вариантов. Еще один удобный раздел - это результаты по задаче. Это могут быть новые знания о системе, например точные данные о нагрузочной способности сервиса или новая информация о полноте данных в источнике. Сюда я также заношу и какие-то однострочные команды на bash или выдержки из кода, чтобы переиспользовать в дальнейшем. 3/3

Как я веду документацию по задаче 2/3 Документация - это очевидная и простая для понимания вещь, но которую всегда лень делать. В предыдущем посте я рассказал о мотивации все-таки вести собственную документацию. Задачи, о которых идет речь в посте - задачи на разработку на python, аналитика в базах данных, исследование источников данных, проектирование или настройка уже функционирующих проектов. У меня всегда железно выделяются как минимум четыре раздела: вводные по задаче, прогресс, вопросы и результаты. Вводные данные я заполняю самостоятельно. В моей практике, чаще всего данные для задачи лежат как минимум в двух местах - таск-трекере и в чатах. Чтобы не заниматься сталкерством каждый раз, когда мне нужна инфа по задаче, я составляю ее резюме для себя. Сюда прилетают кусочки сообщений из чатов, записи в таск трекере, уточненные мною требования. Этот раздел я, как правило, создаю в начале начале задачи и редко редактирую в процессе. Раздел "прогресс" - на каком я сейчас этапе в виде списка шагов. В следующем посте как "вопросы и ответы" помогают закрывать задачи быстрее 2/3

Зачем писать документацию в проекте и отдельной задаче? Не доверяйте памяти. Не заставляйте себя хранить постоянно в памяти то, что можно сдампить в документ и оставить на время. Даже ведение журнала предпринятых действий и новой информации по отдельно взятой задаче или дебагу будет очень полезно. Это поможет вам: систематизировать работу здесь и сейчас, увидеть всю картину задачи из отдельных паззлов и сохранить полезные знания для коллег. Нужда вести заметки параллельно с разработкой кода и настройкой систем для меня сейчас так же очевидна, как год назад было очевидно, что заметки - для слабаков. К этому я пришёл в своей практике. В следующем посте я расскажу, как я веду документацию по задаче. 1/3

Читаю курс по потоковой обработке данных и Kafka. Дан базовый пример сообщения, в котором указаны одновременно "partition" и "key". { "topic":"base", "partition":2, "key":2, .... "payload":"........." } Если поле "key" служит для определения партиции самой кафкой, то зачем может понадобиться дополнительно, явно указывать "partition"?

После не значит из-за. Дебажил пайплайн выкатки питон-приложение через виртуальное окружение и airflow. Почему-то вдруг на сервере сломался conda для всех пользователей. Первая мысль, которая пришла в голову : это я все сломал. Но "после" не значит и"из-за". Принял информацию к сведению и развернул сервис через cron.