Search
Write a publication
Pull to refresh
11
0
Богдан Петров @BogdanPetrov

User

Send message

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

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

Не совсем понял, как изложенное в статье объясняет вывод

Я просто высказался, что NumPy — это худший язык для работы с массивами, кроме всех других языков работы с массивами.

Пересаживался с MATLAB на Python и NumPy тогда оказался спасением. На мой взгляд работа с многомерными таблицами - это не та область, где всегда можно обеспечить "очевидность" происходящего.

Когда я читаю какой-то код, чтобы было «очевидно», что он делает.

Вот, кстати, пример кода на MATLAB (кусок численного решения 3D задачи со временем, то есть идет работа с таблицами с 4 измерениями). Тяжело читать? Да, очень. Написать при этом было не очень сложно и сильно пересекается с тем, что было написано на бумаге.

Скрытый текст
    fxn = cross(p(:,2:N+1,1:N,:) - p(:,1:N,2:N+1,:), p(:,2:N+1,2:N+1,:) - p(:,1:N,1:N,:),4)/2;
    fyn = cross(p(1:N,:,2:N+1,:) - p(2:N+1,:,1:N,:), p(2:N+1,:,2:N+1,:) - p(1:N,:,1:N,:),4)/2;
    fzn = cross(p(2:N+1,1:N,:,:) - p(1:N,2:N+1,:,:), p(2:N+1,2:N+1,:,:) - p(1:N,1:N,:,:),4)/2;

    % центры граней
    fxc = (p(:,1:N,1:N,:) + p(:,1:N,2:N+1,:) + p(:,2:N+1,2:N+1,:) + p(:,2:N+1,1:N,:))/4;
    fyc = (p(1:N,:,1:N,:) + p(2:N+1,:,1:N,:) + p(2:N+1,:,2:N+1,:) + p(1:N,:,2:N+1,:))/4;
    fzc = (p(1:N,1:N,:,:) + p(1:N,2:N+1,:,:) + p(2:N+1,2:N+1,:,:) + p(2:N+1,1:N,:,:))/4;

    % центры ячеек
    C = ( p(1:N,1:N,1:N,:) + p(1:N,1:N,2:N+1,:) + p(1:N,2:N+1,1:N,:) + p(1:N,2:N+1,2:N+1,:) + ...
          p(2:N+1,1:N,1:N,:) + p(2:N+1,1:N,2:N+1,:) + p(2:N+1,2:N+1,1:N,:) + p(2:N+1,2:N+1,2:N+1,:) )/8;

    % объемы ячеек
    V = 1/3 * ( - dot(fxn(1:N,:,:,:),fxc(1:N,:,:,:),4) + dot(fxn(2:N+1,:,:,:),fxc(2:N+1,:,:,:),4) ...
                - dot(fyn(:,1:N,:,:),fyc(:,1:N,:,:),4) + dot(fyn(:,2:N+1,:,:),fyc(:,2:N+1,:,:),4) ...
                - dot(fzn(:,:,1:N,:),fzc(:,:,1:N,:),4) + dot(fzn(:,:,2:N+1,:),fzc(:,:,2:N+1,:),4));
        
    % объемы октаэдров
    fxv = 1/3 * ( abs(dot(C(2:N,:,:,:) - p(2:N,1:N,1:N,:),fxn(2:N,:,:,:),4)) + ...
                  abs(dot(C(1:N-1,:,:,:) - p(2:N,1:N,1:N,:),fxn(2:N,:,:,:),4)) );
    fyv = 1/3 * ( abs(dot(C(:,2:N,:,:) - p(1:N,2:N,1:N,:),fyn(:,2:N,:,:),4)) + ...
                  abs(dot(C(:,1:N-1,:,:) - p(1:N,2:N,1:N,:),fyn(:,2:N,:,:),4)) );
    fzv = 1/3 * ( abs(dot(C(:,:,2:N,:) - p(1:N,1:N,2:N,:),fzn(:,:,2:N,:),4)) + ...
                  abs(dot(C(:,:,1:N-1,:) - p(1:N,1:N,2:N,:),fzn(:,:,2:N,:),4)) );
              
    % коэффициенты alpha
    fxa = alpha( x(2:N,1:N,1:N), y(2:N,1:N,1:N), z(2:N,1:N,1:N), ...
                 x(2:N,1:N,2:N+1), y(2:N,1:N,2:N+1), z(2:N,1:N,2:N+1), ...
                 x(2:N,2:N+1,2:N+1), y(2:N,2:N+1,2:N+1), z(2:N,2:N+1,2:N+1), ...
                 x(2:N,2:N+1,1:N), y(2:N,2:N+1,1:N), z(2:N,2:N+1,1:N), ...
                 C(2:N,:,:,1), C(2:N,:,:,2), C(2:N,:,:,3), ...
                 C(1:N-1,:,:,1), C(1:N-1,:,:,2), C(1:N-1,:,:,3) );
    fya = alpha( x(1:N,2:N,1:N), y(1:N,2:N,1:N), z(1:N,2:N,1:N), ...
                 x(2:N+1,2:N,1:N), y(2:N+1,2:N,1:N), z(2:N+1,2:N,1:N), ...
                 x(2:N+1,2:N,2:N+1), y(2:N+1,2:N,2:N+1), z(2:N+1,2:N,2:N+1), ...
                 x(1:N,2:N,2:N+1), y(1:N,2:N,2:N+1), z(1:N,2:N,2:N+1), ...
                 C(:,2:N,:,1),  C(:,2:N,:,2),  C(:,2:N,:,3), ...
                 C(:,1:N-1,:,1), C(:,1:N-1,:,2), C(:,1:N-1,:,3));
    fza = alpha( x(1:N,1:N,2:N), y(1:N,1:N,2:N), z(1:N,1:N,2:N), ...
                 x(1:N,2:N+1,2:N), y(1:N,2:N+1,2:N), z(1:N,2:N+1,2:N), ...
                 x(2:N+1,2:N+1,2:N), y(2:N+1,2:N+1,2:N), z(2:N+1,2:N+1,2:N), ...
                 x(2:N+1,1:N,2:N), y(2:N+1,1:N,2:N), z(2:N+1,1:N,2:N), ...
                 C(:,:,2:N,1),  C(:,:,2:N,2),  C(:,:,2:N,3), ...
                 C(:,:,1:N-1,1), C(:,:,1:N-1,2), C(:,:,1:N-1,3));

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

Общение с соседом

Ссылки на посты на пикабу по теме шума / вибрации / гула в квартире, которые собрал в процессе поиска источника шума

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

За обзор некоторых инструментов спасибо. Но если по сути задачи, то разве не очевидно, что кастомизация мельчайших деталей не будет доступна в большинстве BI-инструментов? На мой взгляд, у них цель немного другая: покрыть 99% потребностей в визуализации. Для всего остального есть D3.js, ggplot2 и тд и тп

Вот пример кода на R с использованием ggplot2:

library(ggplot2)

url <- 'https://docs.google.com/spreadsheets/d/1rJL_v0OVTvZpvrCbNJHdSAemrIkcDdBfsoQlrJvEt34/edit?gid=0#gid=0'
df <- readr::read_csv(gsheet::construct_download_url(url))

ggplot(df, aes(x=Years_At_Company, y=Performance_Rating)) +
  geom_point(aes(size=Absences)) +
  geom_smooth(aes(color=Department), method='lm', se=F) +
  facet_wrap(~ Department) +
  theme_minimal()

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

Если хочется добавить сопроводительный текст, то можно обернуть это все в R Markdown.

Скрытый текст

  1. Лучше собирать лишние данные, чем страдать от того, что их не хватает.

  2. Хорошая практика – подумать на этапе аналитики о том, какие данные и для чего хочется собирать в рамках задачи.

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

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

Спустя 4 года ссылки все еще рабочие!)

Делаю локальную копию одного сайта, который обновлялся в период с 2009 по 2017 год, но пока все еще доступен. Обратил внимание, что половина ссылок уже невалидны (собственно, почему и зашел перечитать этот пост).

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

Кажется, что сейчас на практике решение этой проблемы сводится только к https://web.archive.org/.

История с тем, что решение через RANK кто-то может считать единственно верным, мне кажется немного натянутой.

Вообще, сам тест действительно очень древний, мне он тоже попадался. Раскопки привели к статье на хабре аж 2013 года: https://habr.com/ru/articles/181033/

А самое забавное, что она опубликована 27 мая, как и тест на сайте jitbit, если смотреть через веб-архив: http://web.archive.org/web/20130607185217/https://www.jitbit.com/news/181-jitbits-sql-interview-questions/

Вот только наборы задач в статье на хабре и на сайте jitbit отличаются, совпадают только 4 задачи, включая задачу с поиском сотрудников с максимальной зарплатой (идет под номером 2).

Так вот дело в том, что в оригинальной статье приведено как раз другое решение:

select a.*
from   employee a
where  a.salary = ( select max(salary) from employee b
                    where  b.department_id = a.department_id )

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

Честно говоря, в таком случае я даже не знаю, зачем мне был бы нужен DuckDB, обошелся бы polars

Что-то сложнее COUNT(*) пробовали запускать? У меня вот как-то не сложилось. Натравил на директорию с parquet-файлами. Нужно было воспроизвести логику с DENSE_RANK и GROUP BY, запрос все время вылетал по памяти. Один из вариантов запросов для решения той же проблемы наоборот стал вечно крутиться. Пришлось обрабатывать все файлы в цикле и склеивать каждый новый файл с результатами обработки всех предыдущих. Особо деталей не приведу, так как было давно, но суть в том, что была надежда просто написать SQL и получить результат, но магии не случилось, поэтому пришлось писать код.

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

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

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

Не в курсе, есть ли у вас такие наработки, но еще можно двигаться в сторону DQ-дэшбордов и интеграции с каталогом данных.

Для городов это не актуально, а мне были нужны именно они, без пгт и тд

Повторяющихся названий городов не так много и они в разных регионах

Когда бизнес просит «просто выгрузить файлик с городами», нужно понять, как он эти данные будет использовать

Будучи младшим специалистом работал с рядом задач, в которых фигурировала сущность "Город". Чем больше я над ними работал, тем меньше понимал, что такое город и для чего он вообще нужен. В итоге для себя вопрос закрыл обработкой результатов переписи населения. Причем это тоже задача не из разряда эксельки распарсить. Там и ошибки и опечатки и изменения перечня городов год к году. Получился список вида: Год, Код региона, Название города, Население. Потом через сервис геокодирования получил еще координаты центров городов. Этого оказалось достаточно.

На сайте Росстата есть несколько разделов: Статистика / Переписи населения или Статистика / Официальная статистика / Население. Но ни там ни там не будет подробной информации по годам. Архивы по годам лежат в: Публикации / Каталог публикаций / Численность населения Российской Федерации по муниципальным образованиям.

Спасибо за сравнение, увидел для себя отдельные интересные моменты. Но, честно говоря, немного поверхностно получилось, ничего критичного не увидел (а хотелось бы). Я MySQL не пользовался и все перечисленное не вызывает особых вопросов.

Спасибо за статью. Далеко не со всем согласен, но есть над чем подумать. Понравилась идея с листом бумаги. Думаю, ключевой момент здесь - ограничение этого самого листа. Современные инструменты позволяют завести, создать бесконечное число задач, переделать которые не хватит рабочего времени. Какие-то вещи надо уметь просто игнорировать (не вносить на лист). Об этом в статье тоже сказано, помогает вопрос:

зачем нужно выполнить эту задачу? она приближает к цели?

С одной стороны, очередное упоминание R и dplyr это круто. С другой стороны - заметка странноватая и непонятно для кого. Новичкам вряд ли будет что-то понятно, так как нет ни слова про оператор %>%. Приведены функции dplyr, но не все и нет ссылки на документацию: https://dplyr.tidyverse.org/reference/index.html. Для чтения CSV используется read.csv, вместо readr::read_csv из того же Tidyverse.

Было несколько попыток начать вести учет с помощью сторонних приложений. Но успешной оказалась только та, когда в итоге сделал свое приложение на R (shiny) в 2017 году. С тех пор в нем и веду. За все время было несколько апдейтов: импорт чеков; возможность загрузить годовой план по категориям и сверяться с ним; автоматическая классификация товаров в чеках; отчет за период по интересующим меня метрикам.

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

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

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

Скриншоты

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

Вот пример продуктовой корзины за первые 3 месяца 2024 года

Можно углубляться в детализацию
Можно углубляться в детализацию

Классификатор продуктов. Пополняю в полуавтоматическом режиме пользуясь подсказками от модели.

Общий вид план-факт по накоплениям, также есть и детализация.

Можно строить сводные таблички.

Изменения в тратах год к году (на примере категории растений 2023 к 2022 году)

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

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

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

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

За это время ничего не поменялось?

Information

Rating
6,139-th
Location
Москва, Москва и Московская обл., Россия
Registered
Activity