Интересное что-то – Telegram
Интересное что-то
517 subscribers
2.72K photos
253 videos
138 files
4.52K links
Материалы и мысли, понадерганные отовсюду
Блог: https://news.1rj.ru/str/asisakov_channel
Чат: https://news.1rj.ru/str/youknowds_chat
Download Telegram
Forwarded from Vladimir
У нас вопрос образовался. Вот мы арендовали yandex compute cloud, можем в него ходить по ssh и все такое. Код для бота мы залили в github. Теперь пытаемся положить код бота на тачку в клауде, чтобы бот хостился не локально, а на клауде. Как мне кажется, тут появляются 4 возможных сценария:
1. Залить код вручную. Насколько я понял, из web ui невозможно попасть в файловый менеджер тачки и просто положить код на диск
2. Воспользоваться object storage. Это отдельный сервис (может отдельно тарифицироваться), и как будто это предназначено немного для других целей
3. Спуллить код из гита вручную в консоли и запустить бота. Просто, но может быть неудобно каждый раз вручную пуллить и перезапускать бота
4. Настроить CI\CD, чтобы при обновлении кода бота он пуллил новый код на клауд тачку и перезапускал бота. Пока что выглядит неизвестно, пугающе и вообще непонятно, что это нам действительно нужно.

Как поступают в таких ситуациях и кто как сделал у себя в проекте?
Forwarded from Slava Polianskii
Vladimir
У нас вопрос образовался. Вот мы арендовали yandex compute cloud, можем в него ходить по ssh и все такое. Код для бота мы залили в github. Теперь пытаемся положить код бота на тачку в клауде, чтобы бот хостился не локально, а на клауде. Как мне кажется, тут…
Обычно используется пункт 4. За тем исключением, что чаще на сервер попадает не сам код, а собранный docker образ приложения. На сервере образ просто запускается в составе стека, либо одиночного сервиса.
Можно собрать образ локально, чтобы не возмться с настройкой ci/cd
Forwarded from Slava Polianskii
Для пересылки образа с локальной машины на сервер можно использовать registry, либо упаковать его в файл и переслать стандартными методами

https://stackoverflow.com/questions/23935141/how-to-copy-docker-images-from-one-host-to-another-without-using-a-repository
#recommender
Я конечно не люблю все эти мигающие штуки, но контент хороший
Если не отображается - там о построении рекомендательных систем
Forwarded from Блог о Data Science 💻 (Red Powerful)
🔤🔤🔤 🔤🔤🔤

Ждали, а вот и они!

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

System design [1]

System design [2]

How rec sys work

Content Based

Collaborative filtering

HSE lecture

Rec Sys Google cloud

Cookbook

Trends in Rec Sys

NN rec sys

Practice rec sys [1]

Practice rec sys [2]

Practice MTS [1]

Practice MTS [2]

Practice MTS [3]

Practice MTS [4]

#recsys

120 Эмодзи и делаю про парсинг 🙃
Please open Telegram to view this post
VIEW IN TELEGRAM
MongoDB Python [Курс PyMongo] // 11 видео

Содержание:
▪️MongoDB Python | #0 Информация о курсе | PyMongo
▪️MongoDB Python | #1 Теория и основные технологии СУБД | PyMongo
▪️MongoDB Python | #2 Установка админки с интерфейсом на сайте | PyMongo
▪️MongoDB Python | #3 Установка MongoDB на Linux сервер | PyMongo
▪️MongoDB Python | #4 Запись значений в коллекции | PyMongo

Смотреть бесплатно

#Python
#nlp #interesting
Интересная штука оценить ваше понимание контекстов и близости смыслов

https://contexto.me/
Еще прикольно про трейдоффы дизайна – как прийти к компромиссу, когда нужно учитывать и пользователей, и их задачи, и контекст использования.

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

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

Прикольный подход, я такие штуки раньше не встречала. Схемку сложновато читать, но интерестно.

ps в доп материалах лежит презентация и есть коллекция дэшиков, основные благодарности идут Benjamin Bach
#career #interview
Борис делится опытом и лайфхаками
Forwarded from Борис опять
Проводим мок собеседования с ребятами, которых я консультирую по поиску работы. Поделюсь ошибками, которые встречались у всех, и советами, как их избегать.

Ответ на "расскажите о себе" должен отскакивать от зубов. Этот вопрос будут задавать каждый раз. Здесь происходит просто море ошибок. Люди начинают говорить что-то вроде "начал работать всего год назад", указывать на свои недостатки и другими способами себя закапывать. Это задает тон всему собеседованию. Есть только один способ с этим работать: сесть перед вебкой, несколько раз рассказать себе ответ на этот вопрос и посмотреть запись. Ответ должен быть короткий, по делу и в меру продающий: что ты умеешь, что ты можешь предложить и чего ты хочешь.

Вторая типичная ошибка по поведенческой части: после рассказа про опыт непонятно, в какой роли человек был на последнем проекте и какая у него была степень ответственности. Брал идеально расписанные тикеты и делал в одиночку? Тащил всю команду? Принимал архитектурные решения? Писал лапшу в ноутбуках и скидывал инженерам? Должно быть кристально ясно.

По технической части. Самая глупая ошибка, которую совершили все: не знать ответы на вопросы по Python, которые точно спрашивают. Что такое декоратор, что может быть ключом словаря, что такое GIL, как работает garbage collection. Я специально включал в каждый мок собес вопросы, которые только что попадались другим ребятам на собеседованиях, и ребята часто не знали ответов. Как с этим работать: открываем гугл, находим списки "топ 10 вопросов по Python" и изучаем. Меня так однажды забраковали в Яндекс, потому что я не знал, что такое контекстный менеджер. Очень глупая ситуация, по возможности избегайте.

Применимо не только к Python. Несколько примеров типичных вопросов по ML: что такое регуляризация, как работает логрегрессия, задачки на формулу Байеса и матрицы ошибок, почему градиентный бустинг называют градиентным, что будет если у случайного леса удалить первое дерево (и аналогично для градиентного бустинга), производная сложной функции (chain rule).

Другая ошибка: пытаться выкрутиться, когда не знаешь. Не знаешь ответ, но вроде бы что-то слышал, пытаешься что-то придумать на ходу и в итоге показываешь еще уйму мест, в которых ты ничего не знаешь. Так я задал вопрос про GIL, а в итоге меня убеждали, что в Python нет мультипроцессинга, но зато есть мультитрединг. Это не только закапывает вас, но и тратит время интервьюера. Лучше просто сказать, что не знаешь.
Forwarded from Pavel Pikulev
Вы должны четко понимать что рекрутер ≠ заказчик.

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

2) рекрутер (если в компании нет крутого HR BP) нифига не разбирается в том, что делает заказчик и кто в реальности ему нужен.

И вот 1 и 2 собираются и начинают брейнштормить по требованиям к кандидатам 😂😂😂

Результат, как правило, какой-то шаблонный набор требований, который «вроде ок» для рекрутера и который «ну ты же рекрутер, тебе же виднее» для заказчика.

Очень многое lost in translation

Потом случаются две вещи:

1) так как описание написано фигово - на него откликается фиг знает кто

2) если отклики смотрит рекрутер, он применяет к ним какие-то свои критерии, соответствующие его представлениям о прекрасном, но в большинстве случаев не совпадающие с критериями бизнес-владельцев

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

Выводы здесь простые и их 2:

1) описания вакансии в подавляющем большинстве случаев написаны фигово, и на требования там надо ориентироваться лишь примерно. Высока вероятность, что в реальности людям надо совсем не то, что там написано.

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