Forwarded from Vladimir
У нас вопрос образовался. Вот мы арендовали yandex compute cloud, можем в него ходить по ssh и все такое. Код для бота мы залили в github. Теперь пытаемся положить код бота на тачку в клауде, чтобы бот хостился не локально, а на клауде. Как мне кажется, тут появляются 4 возможных сценария:
1. Залить код вручную. Насколько я понял, из web ui невозможно попасть в файловый менеджер тачки и просто положить код на диск
2. Воспользоваться object storage. Это отдельный сервис (может отдельно тарифицироваться), и как будто это предназначено немного для других целей
3. Спуллить код из гита вручную в консоли и запустить бота. Просто, но может быть неудобно каждый раз вручную пуллить и перезапускать бота
4. Настроить CI\CD, чтобы при обновлении кода бота он пуллил новый код на клауд тачку и перезапускал бота. Пока что выглядит неизвестно, пугающе и вообще непонятно, что это нам действительно нужно.
Как поступают в таких ситуациях и кто как сделал у себя в проекте?
1. Залить код вручную. Насколько я понял, из web ui невозможно попасть в файловый менеджер тачки и просто положить код на диск
2. Воспользоваться object storage. Это отдельный сервис (может отдельно тарифицироваться), и как будто это предназначено немного для других целей
3. Спуллить код из гита вручную в консоли и запустить бота. Просто, но может быть неудобно каждый раз вручную пуллить и перезапускать бота
4. Настроить CI\CD, чтобы при обновлении кода бота он пуллил новый код на клауд тачку и перезапускал бота. Пока что выглядит неизвестно, пугающе и вообще непонятно, что это нам действительно нужно.
Как поступают в таких ситуациях и кто как сделал у себя в проекте?
Forwarded from Slava Polianskii
Vladimir
У нас вопрос образовался. Вот мы арендовали yandex compute cloud, можем в него ходить по ssh и все такое. Код для бота мы залили в github. Теперь пытаемся положить код бота на тачку в клауде, чтобы бот хостился не локально, а на клауде. Как мне кажется, тут…
Обычно используется пункт 4. За тем исключением, что чаще на сервер попадает не сам код, а собранный docker образ приложения. На сервере образ просто запускается в составе стека, либо одиночного сервиса.
Можно собрать образ локально, чтобы не возмться с настройкой ci/cd
Можно собрать образ локально, чтобы не возмться с настройкой 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
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)
Ждали, а вот и они!
Список будет пополняться как минимум еще есть пару крутых книг и статей,
которые могу порекомендовать, но чуть позже
#recsys
120 Эмодзи и делаю про парсинг
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Кодим на Коленке | Уроки по программированию
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
Содержание:
▪️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/
Интересная штука оценить ваше понимание контекстов и близости смыслов
https://contexto.me/
Forwarded from настенька и графики
Еще прикольно про трейдоффы дизайна – как прийти к компромиссу, когда нужно учитывать и пользователей, и их задачи, и контекст использования.
Условно есть 4 параметра устройства дэшборда: размер экрана, количество страниц, уровень абстракции данных и объем интерактивности. Каждый из этих параметров можно повышать или понижать. Например, показывать на большом экране или маленьком, брать больше или меньше страниц в дэш, показывать только агрегаты или детализироваться до меньших измерений, добавлять или убавлять возможности фильтрации, использования параметров и тд.
Чтобы достигнуть баланса, можно пользоваться их схемой, уменьшая одни параметры и увеличивая другие. Например, если вы хотите уменьшить размеры экрана, то увеличьте кличество страниц, объем интерактивности и уровень абстрации.
Прикольный подход, я такие штуки раньше не встречала. Схемку сложновато читать, но интерестно.
ps в доп материалах лежит презентация и есть коллекция дэшиков, основные благодарности идут Benjamin Bach
Условно есть 4 параметра устройства дэшборда: размер экрана, количество страниц, уровень абстракции данных и объем интерактивности. Каждый из этих параметров можно повышать или понижать. Например, показывать на большом экране или маленьком, брать больше или меньше страниц в дэш, показывать только агрегаты или детализироваться до меньших измерений, добавлять или убавлять возможности фильтрации, использования параметров и тд.
Чтобы достигнуть баланса, можно пользоваться их схемой, уменьшая одни параметры и увеличивая другие. Например, если вы хотите уменьшить размеры экрана, то увеличьте кличество страниц, объем интерактивности и уровень абстрации.
Прикольный подход, я такие штуки раньше не встречала. Схемку сложновато читать, но интерестно.
ps в доп материалах лежит презентация и есть коллекция дэшиков, основные благодарности идут Benjamin Bach
Forwarded from Борис опять
Проводим мок собеседования с ребятами, которых я консультирую по поиску работы. Поделюсь ошибками, которые встречались у всех, и советами, как их избегать.
Ответ на "расскажите о себе" должен отскакивать от зубов. Этот вопрос будут задавать каждый раз. Здесь происходит просто море ошибок. Люди начинают говорить что-то вроде "начал работать всего год назад", указывать на свои недостатки и другими способами себя закапывать. Это задает тон всему собеседованию. Есть только один способ с этим работать: сесть перед вебкой, несколько раз рассказать себе ответ на этот вопрос и посмотреть запись. Ответ должен быть короткий, по делу и в меру продающий: что ты умеешь, что ты можешь предложить и чего ты хочешь.
Вторая типичная ошибка по поведенческой части: после рассказа про опыт непонятно, в какой роли человек был на последнем проекте и какая у него была степень ответственности. Брал идеально расписанные тикеты и делал в одиночку? Тащил всю команду? Принимал архитектурные решения? Писал лапшу в ноутбуках и скидывал инженерам? Должно быть кристально ясно.
По технической части. Самая глупая ошибка, которую совершили все: не знать ответы на вопросы по Python, которые точно спрашивают. Что такое декоратор, что может быть ключом словаря, что такое GIL, как работает garbage collection. Я специально включал в каждый мок собес вопросы, которые только что попадались другим ребятам на собеседованиях, и ребята часто не знали ответов. Как с этим работать: открываем гугл, находим списки "топ 10 вопросов по Python" и изучаем. Меня так однажды забраковали в Яндекс, потому что я не знал, что такое контекстный менеджер. Очень глупая ситуация, по возможности избегайте.
Применимо не только к Python. Несколько примеров типичных вопросов по ML: что такое регуляризация, как работает логрегрессия, задачки на формулу Байеса и матрицы ошибок, почему градиентный бустинг называют градиентным, что будет если у случайного леса удалить первое дерево (и аналогично для градиентного бустинга), производная сложной функции (chain rule).
Другая ошибка: пытаться выкрутиться, когда не знаешь. Не знаешь ответ, но вроде бы что-то слышал, пытаешься что-то придумать на ходу и в итоге показываешь еще уйму мест, в которых ты ничего не знаешь. Так я задал вопрос про GIL, а в итоге меня убеждали, что в Python нет мультипроцессинга, но зато есть мультитрединг. Это не только закапывает вас, но и тратит время интервьюера. Лучше просто сказать, что не знаешь.
Ответ на "расскажите о себе" должен отскакивать от зубов. Этот вопрос будут задавать каждый раз. Здесь происходит просто море ошибок. Люди начинают говорить что-то вроде "начал работать всего год назад", указывать на свои недостатки и другими способами себя закапывать. Это задает тон всему собеседованию. Есть только один способ с этим работать: сесть перед вебкой, несколько раз рассказать себе ответ на этот вопрос и посмотреть запись. Ответ должен быть короткий, по делу и в меру продающий: что ты умеешь, что ты можешь предложить и чего ты хочешь.
Вторая типичная ошибка по поведенческой части: после рассказа про опыт непонятно, в какой роли человек был на последнем проекте и какая у него была степень ответственности. Брал идеально расписанные тикеты и делал в одиночку? Тащил всю команду? Принимал архитектурные решения? Писал лапшу в ноутбуках и скидывал инженерам? Должно быть кристально ясно.
По технической части. Самая глупая ошибка, которую совершили все: не знать ответы на вопросы по 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) всегда старайтесь откликнуться напрямую бизнес-владельцу вакансии, а не рекрутеру. Шансы на успех по многим причинам (не только по этой) гораздо выше.
1) заказчик из подразделения которое нанимает очень часто имеет сложности с тем, чтобы сформулировать кто конкретно ему нужен. Большие сложности. Он также нифига не понимает, как это соотносится с тем, что есть на рынке.
2) рекрутер (если в компании нет крутого HR BP) нифига не разбирается в том, что делает заказчик и кто в реальности ему нужен.
И вот 1 и 2 собираются и начинают брейнштормить по требованиям к кандидатам 😂😂😂
Результат, как правило, какой-то шаблонный набор требований, который «вроде ок» для рекрутера и который «ну ты же рекрутер, тебе же виднее» для заказчика.
Очень многое lost in translation
Потом случаются две вещи:
1) так как описание написано фигово - на него откликается фиг знает кто
2) если отклики смотрит рекрутер, он применяет к ним какие-то свои критерии, соответствующие его представлениям о прекрасном, но в большинстве случаев не совпадающие с критериями бизнес-владельцев
Если отклики смотрит бизнес-владелец, то он мало смотрит на формальные критерии. Ему важно то, насколько человек соответствует его внутреннему ментальному шаблону идеального кандидата (который он на шаге 1 не сумел донести до рекрутера ))). Он думает, где может пойти на компромисс с реальностью, а где нет.
Выводы здесь простые и их 2:
1) описания вакансии в подавляющем большинстве случаев написаны фигово, и на требования там надо ориентироваться лишь примерно. Высока вероятность, что в реальности людям надо совсем не то, что там написано.
2) всегда старайтесь откликнуться напрямую бизнес-владельцу вакансии, а не рекрутеру. Шансы на успех по многим причинам (не только по этой) гораздо выше.