Когда учился в яндекс.практикуме, по прошествии примерно половины обучения в слак прилетел "конкурс" следующего характера: "напишите положительный отзыв в любом крупном сообществе\отзовике, первые три места получат умную колонку\подписку плюс\набор стикеров".
Суперсет хорош как self-hosted решение, для крупных компаний он, разумеется, не подойдет, но для стартапов и малых-средних компаний - почему бы и нет? К тому же он open source (при наличии навыков можно дорабатывать под свои нужды).
Metabase тоже self-hosted, так же умеет из коробки в ssh (косо смотрим на Power BI где тикет висит уже 10+ лет), а кроме того она предоставляет возможность строить чарты на основе SQL-запросов что весьма удобно.
Был ещё какой-то третий подобный бесплатный BI, но я забыл его название :(
Имхо подобные продукты (open source + self-host) в нынешних реалиях как раз именно то, что нужно :) да и СБ никто не отменял - товарищи сильно не любят когда данные из внутреннего контура попадают в облако :)
1) шелкография + пошив сумок + уф-лак + широкоформатка - полная чернота, ТК РФ для них не существует; 2) оффсет - довольно белое, но серые зоны были (+печатали то, что должно быть зарубежным); 3) шелкотрафаретный лак (на обложки книг, визитки и тд) - серое; 4) а ещё у начальницы из п.3 была оперативная полиграфия и там была чернота; 0) не совсем полиграфия, но схоже - лазерная резка и гравировка (брендирование), плоттерная резка - чернее этого места в природе не существует)).
отличный канал, спасибо за ссылку (смотрел его несколько лет назад на английском), больше всего мне там понравилось видео про псевдослучайные числа в DOOM'e
Если я правильно понял - то Вам нужно чтобы кандидат понимал что такое план запроса (и, соответственно, виды запросов - hash join, merge join, cartesian и т.д.), как его оптимизировать, а так же понимал на каких объёмах данных что является допустимым, а что - нет :)
Т.е. Вам нужен SQL-разработчик\Data Engineer (тут эти знания априори должны быть) со склонностью к бизнес\системной аналитике.
Я прошу прощения, но сильной разницы (на уровне написания запросов) между oracle\postgresql я не заметил (по своему опыту), ms sql (опять же имхо) отличается select top (xxx) вместо select ... limit 10. Скажу даже больше, для меня greenplum от postgresql (опять же, в плане написания запросов) вообще ничем не отличается (я знаю про главную неймноду, кластеры, параллельное вычисление, партицирование и тд).
Да и в spark-sql я не увидел каких-то сверхъестественных отличий от "стандартного" синтаксиса (пишу запросы через HUE или spark.sql.context в питоне к parquet\hive-представлениям).
Но вот если Вам нужно чтобы кандидат знал как это всё "под капотом" работает (глубже уровня что есть оптимизатор который всё оптимизирует) - тогда да, найти такого человека будет непросто..
я получается неправильно условие задачи понял, думал что после каждой итерации мы получаем новую веревку и её складываем со следующей, а не то, что нужно найти сумму всех складываний веревок - тогда, конечно, надо складывать минимальные по очереди :)
Насколько я понимаю, после каждой итерации нужно получать верёвки минимальной длинны, т.е. по сути мы создаем массив из длин веревок и соединяем первую и последнюю, вторую и предпоследнюю и тд, и так на каждой итерации.
Это очень сильно напоминает главу из книги Перельмана ("Занимательная арифметика" если не ошибаюсь) где учитель дал ученикам задачу сложить все числа от 1 до 100..
Как по мне, главный плюс оффлайн карт - именно пользование оффлайн (на отпуске в Греции интернет был только в отеле, местную симку не покупал и оффлайн карты очень сильно выручали - как для построения маршрутов, так и отмечать междугородние автобусные остановки).
так все (или почти все) эти данные есть у налоговой (паспорт, номер телефона, данные компании которая платит зарплату, оквэд этой самой компании), которая в том числе занимается продажей этих обезличенных (под вопросом) данных государству и окологосударственному бизнесу
есть хороший ролик на ютубе, поищите "mygap налоговая", там про то, как налоговая наращивает бигдату
К сожалению полиграфическое прошлое не отпускает (и я читал до этого историю Dinners Club), зацепил момент:
Идея понравилась основателям, и они предложили её внедрить владельцу ресторана, в котором обедали. Для идентификации посетителей было решено использовать металлические эмбоссированные карты, очень распространенные на тот момент.
Но если почитать историю целиком (например тут), то мы узнаем что "...Они печатались на прямоугольнике плотной бумаги..." (1950 год).
А далее (например, здесь) "...В 1961-м вместо бумажных карточек начинают использовать пластиковые..."
Соответственно (имхо) Dinners Club - это практически отцы-основатели (не в том плане что сами придумали, а в том плане что ввели в широкое обращение и сделали популярными) современных пластиковых карт (которые не так быстро изнашивались как бумажные), откуда Вы взяли металлические эмбоссированные карты ?
Я не придираюсь, просто интересно где ложь, а где истина :)
Когда учился в яндекс.практикуме, по прошествии примерно половины обучения в слак прилетел "конкурс" следующего характера: "напишите положительный отзыв в любом крупном сообществе\отзовике, первые три места получат умную колонку\подписку плюс\набор стикеров".
Суперсет хорош как self-hosted решение, для крупных компаний он, разумеется, не подойдет, но для стартапов и малых-средних компаний - почему бы и нет? К тому же он open source (при наличии навыков можно дорабатывать под свои нужды).
Metabase тоже self-hosted, так же умеет из коробки в ssh (косо смотрим на Power BI где тикет висит уже 10+ лет), а кроме того она предоставляет возможность строить чарты на основе SQL-запросов что весьма удобно.
Был ещё какой-то третий подобный бесплатный BI, но я забыл его название :(
Имхо подобные продукты (open source + self-host) в нынешних реалиях как раз именно то, что нужно :) да и СБ никто не отменял - товарищи сильно не любят когда данные из внутреннего контура попадают в облако :)
Спасибо за краткий разбор.
Главным считаю перевод ДатаЛенс в бесплатный формат (год назад когда искал варианты BI-решений он был платным).
Было бы интересно почитать про Apache Superset (установленный из докера) или другой бесплатный BI (но не про Metabase - в ней я разбираюсь :))
PS. самописное на python это dash?
работал в полиграфии в Москве 6 лет:
1) шелкография + пошив сумок + уф-лак + широкоформатка - полная чернота, ТК РФ для них не существует;
2) оффсет - довольно белое, но серые зоны были (+печатали то, что должно быть зарубежным);
3) шелкотрафаретный лак (на обложки книг, визитки и тд) - серое;
4) а ещё у начальницы из п.3 была оперативная полиграфия и там была чернота;
0) не совсем полиграфия, но схоже - лазерная резка и гравировка (брендирование), плоттерная резка - чернее этого места в природе не существует)).
отличный канал, спасибо за ссылку (смотрел его несколько лет назад на английском), больше всего мне там понравилось видео про псевдослучайные числа в DOOM'e
Спасибо за ответ.
Если я правильно понял - то Вам нужно чтобы кандидат понимал что такое план запроса (и, соответственно, виды запросов - hash join, merge join, cartesian и т.д.), как его оптимизировать, а так же понимал на каких объёмах данных что является допустимым, а что - нет :)
Т.е. Вам нужен SQL-разработчик\Data Engineer (тут эти знания априори должны быть) со склонностью к бизнес\системной аналитике.
Я прошу прощения, но сильной разницы (на уровне написания запросов) между oracle\postgresql я не заметил (по своему опыту), ms sql (опять же имхо) отличается select top (xxx) вместо select ... limit 10. Скажу даже больше, для меня greenplum от postgresql (опять же, в плане написания запросов) вообще ничем не отличается (я знаю про главную неймноду, кластеры, параллельное вычисление, партицирование и тд).
Да и в spark-sql я не увидел каких-то сверхъестественных отличий от "стандартного" синтаксиса (пишу запросы через HUE или spark.sql.context в питоне к parquet\hive-представлениям).
Но вот если Вам нужно чтобы кандидат знал как это всё "под капотом" работает (глубже уровня что есть оптимизатор который всё оптимизирует) - тогда да, найти такого человека будет непросто..
я получается неправильно условие задачи понял, думал что после каждой итерации мы получаем новую веревку и её складываем со следующей, а не то, что нужно найти сумму всех складываний веревок - тогда, конечно, надо складывать минимальные по очереди :)
не знаю, интуиция)
а вот объясните мне, пожалуйста, откуда вот тут 39 взялось:
Сначала соединим 10 и 5, потом соединим 21 и 3, после чего соединим две полученные верёвки. Стоимость: 15+24+39=78.
мы же соединили
1) 10 + 5 = 15,
2) 21 + 3 = 24,
3) 24 + 15 = 39
Ответ: 39
Или я неправильно условие задачи понимаю?
Насколько я понимаю, после каждой итерации нужно получать верёвки минимальной длинны, т.е. по сути мы создаем массив из длин веревок и соединяем первую и последнюю, вторую и предпоследнюю и тд, и так на каждой итерации.
Это очень сильно напоминает главу из книги Перельмана ("Занимательная арифметика" если не ошибаюсь) где учитель дал ученикам задачу сложить все числа от 1 до 100..
Как по мне, главный плюс оффлайн карт - именно пользование оффлайн (на отпуске в Греции интернет был только в отеле, местную симку не покупал и оффлайн карты очень сильно выручали - как для построения маршрутов, так и отмечать междугородние автобусные остановки).
плюсую за FAR Manager
Про него в слаке в главном треде пишут. А футболку и значок присылают когда 50% курса пройдено.
Спасибо, интересно.
PS. у вас 2 одинаковые картинки где сравнение колоночного формата и heap (497 мб)
я имею ввиду что внутри налоговой данные, само собой, не обезличенные, а вот в каком виде они их поставляют заказчику - тут ничего сказать не могу
так все (или почти все) эти данные есть у налоговой (паспорт, номер телефона, данные компании которая платит зарплату, оквэд этой самой компании), которая в том числе занимается продажей этих обезличенных (под вопросом) данных государству и окологосударственному бизнесу
есть хороший ролик на ютубе, поищите "mygap налоговая", там про то, как налоговая наращивает бигдату
К сожалению полиграфическое прошлое не отпускает (и я читал до этого историю Dinners Club), зацепил момент:
Идея понравилась основателям, и они предложили её внедрить владельцу ресторана, в котором обедали. Для идентификации посетителей было решено использовать металлические эмбоссированные карты, очень распространенные на тот момент.
Но если почитать историю целиком (например тут), то мы узнаем что "...Они печатались на прямоугольнике плотной бумаги..." (1950 год).
А далее (например, здесь) "...В 1961-м вместо бумажных карточек начинают использовать пластиковые..."
Соответственно (имхо) Dinners Club - это практически отцы-основатели (не в том плане что сами придумали, а в том плане что ввели в широкое обращение и сделали популярными) современных пластиковых карт (которые не так быстро изнашивались как бумажные), откуда Вы взяли металлические эмбоссированные карты ?
Я не придираюсь, просто интересно где ложь, а где истина :)
PS/ пошёл ностальгировать на принт-форум
конечно в юпитере)
если бы не юпитер, я бы может никогда и программировать не стал)
в общем в моём комментарии выше я нашел как убрать ошибки (и даже добиться правильной работы кода), посему статью буду читать дальше)
Спасибо, в первом примере помог
await main(), во втором -import nest_asyncionest_asyncio.apply()
@EvilsInterrupt
К сожалению да, Windows :( set_event_loop_policy не помогло
Python 3.9.7
Но это на собственном ноуте, а в проде везде не выше3.6, поэтому, к сожалению, статья про версию 3.10+ для меня мало актуальна) спасибо за ответ