*сижу и жду пока архивируются все коллекции труселей с проекта*

я бы прост назвал Jetbrains Atlassian.

Конечно замахнулись круто, и слак, и гугл календарь, и бейзкамп, и конфлюенс. лол, даже мобайл сразу.

Как бы по швам не разошлись от напряжения

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

№1

Над этой задачей нечего думать. Берём и пишем цикл от 0 (а можно и от 3 сразу) до 1000. Проверяем остаток от деления счетчика на 3 и 5. Если хоть одно равно нулю - прибавляем к переменной с ответом.

№2

Последовательность Фибоначчи многие писали в лоб, возможно, кто-то даже через рекурсию. По решению всё понятно. Получаем число последовательности, проверяем его на чётность. Если нечётное - прибавляем к ответу. И так пока очередной элемент не будет больше 8 лямов.

Основная фишка при решении, в использовании уже ранее посчитанных значений чисел, а не их очередной перёсчет, иначе будет чертовски медленно (а нам нужны элементы до 34 включительно). Подробное описание с примерами доступно по ссылке http://brestprog.by/topics/dp/, где рассказывается о динамическом программировании.

№3

Я сразу пропустил эту задачу и даже не стал вчитываться. Конечно можно написать решение в лоб, перебирать N и генерировать всю эту последовательность чисел, запоминать максимальное количество элементов, но такое мне писать не интересно, ибо не проходит по времени.

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

№4

Звучит очень легко и решается так же. Особенно, при решении в лоб (перебор каждого и попытка деления. Так пока 2019 раз не пройдет условие на простоту). Лично я использовал Решето Эратосфена для получения всех простых чисел на опредёленном отрезке за O(N loglogN), что потом не составило мне труда вывести 2019-ое. Подробнее об алгоритме тут: http://brestprog.by/topics/primesieve/

№5

Моё самое медленное решение. Происходит полный перебор всех пар с n = 10000. Для нахождения делителей пользовался маленькой и логичной оптимизацией (работал до корня от числа). Подробнее о ней тут: http://brestprog.by/topics/factorization/

UPD. Ниже избавление от корня в этой задаче. Работает за O(N sqrt N)

№6

Решение пришло сразу - работать через строки. Так как нам нужен минимальный, то конечно же начинаем свой путь перебора с 1. Алгоритм простой: берём i и умножаем на 2, 3, 4, 5, 6. Переводим полученные числа в строки, сортируем по символам. Теперь все имеют строгий порядок цифр (от 0 до 9), а значит нам остается только сравнить все эти строки на их эквивалентность (s1 = s2 ... = s5). Как только они все равны - мы нашли ответ!

№7

Легчайшая задача которая требует от вас только умение читать из файла и производить в него запись. Открываем файл program.cs, читаем все содержимое, делаем замену //, /* и */ на пустоту, сохраняем в файл newprogram.cs. Это же исходники C#, а не Python'a, поэтому на отступы нам все равно.

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

Если нужно более сильное решение, ну, регулярки в помощь.

№8

А эту задачу даже и не прочитал до сих пор ✨


Все мои решения (без 3 и 8 задачи) на C++: https://codepaste.ml/5bde60cd/

Улучшения решений (5, например) и свои решения (особенно 3 и 8 задачи) кидайте в личку (@MarshalX) 😋

Предложенное улучшение. Избавляемся от квадрата в пятой задаче:

b = d(a)
d(b) = a
d(b) = d(d(a)) = a

Где d - функция нахождения суммы делителей без самого числа.

int t5() {
int n = 10000, answer = 0;

map<int, int> sums;
for (int i = 0; i < n; ++i) {
sums[i] = sum_of_dividers(i);
}

for (int i = 0; i < n; ++i) {
if (i == sums[sums[i]] && i != sums[i]){
answer += i;
}
}

return answer;
}

Где sum_of_dividers - ваша функция. У меня за корень 🌚

Еще несколько месяцев назад мне бы и в голову не пришло накидать какой-то абы дизайн для одностраничного сайта с ипользованием React'a. Я бы просто сделал HTML страничку и ок. Это всё Слава конь, дорофлился 😂

Код тут: https://github.com/MarshalX/yandex-music-token

Нужно это для моего тг ботика: @music_yandex_bot

Классный утренний чилл. Как раз хватило от хаты до шараги. Прикольно, что при разработке ORM/ODM все за пример берут Django ORM (а не алхимию, например) и повторяют её синтаксис. У меня вообще не возникает вопросов к mongoengine. Скорее бы только попробовать.

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

(между двумя парами и этим выбрал это 🌚)

https://youtu.be/E-1xI85Zog8

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

2. Реверс первому. Как часто мы хотим получить настройки пользователя без самого пользователя? Если чуть ли никогда - встроенный.

3. Если элементов в листе слишком много (например, все статьи сайта), то это отдельный документ в связи с огромным количеством данных и их размером при выполнении запроса.

4. Предлагают ограничить размер встроенного дока в 16 мб. Если больше - выносим по понятным причинам. Откуда именно 16 непонятно, видать, из опыта автора. UPD. Это огрань монго.

5. Зависит от того, что мы будем делать с данными. Какие выборки осуществлять, какие сортировки применять. Вообще, очень схоже с 2 пунктом. Всегда ли нам нужен встроенный документ для выполнения какого-либо запроса.

6. Если базу юзаем не только мы, а куча других аппок с разной логикой, то 100 раз думаем как лучше сделать и скорее всего, это будет отдельный документ.

Тэк, мне не хватило букаф в сообщении выше под пикчей.

Короче в пятом вроде ясно, раз мы не одни, то думаем и про то, что на 1, 2, 5 вопросы у них у всех будут разные ответы.

По поводу 4, то вот чет да. У mongoengine max_size в дефолте 10мб, а 16 мб ето отсюда:

The maximum BSON document size is 16 megabytes. https://docs.mongodb.com/manual/reference/limits/

Ну и там же про возможность хранить больше 16мб юзая GridFS API (не знаю еще шо ето( )

📈 Число подписчиков «Яндекс.Музыки» достигло трёх миллионов. Это чуть выше, чем у стриминговых сервисов ВКонтакте и Boom.

Точные данные по Apple Music неизвестны, а Spotify, увы, в России пока ещё не запустился:

https://kod.ru/yandex-music-state-dec-2019/

Первый опыт с MonogoDB: скачал Robo 3T как классный парень, взял базу на heroku от mLab, подключился, зашел посмотреть юзеров и всё, минус Robo 3T. Уносите, давайте другой клиент (я понимаю, что на этой шлюпко-бесплатной тачке скорее всего куча юзеров, но неужели сложно отобразить или шо)

UPD. Юзера всего два и там свалки никакой нет... Studio 3T работает норм

UPD2. У MongoDB Compass вечный loading...

На самом деле без малейшего понятия зачем... Это что, люди ищут бесплатный аналог винды? Какой смысл копировать винду на линухе? Хотя, зачем люди копируют на андроиде iOS (вот эти вот приложения-лончеры, шторки...)

Позиционирует себя этот дистрибут как самый безболезненный переход с винды на линукс (чем? Иконками и меню пуск? Убунта с гномом не, не такие же окошки?)

Я тут что вспомнил. Призыв закончился уже. Пора попробовать новый способ избавиться от армии ✨

В общем у Robo 3T трабле больше чем я про монго знаю (https://github.com/Studio3T/robomongo/issues/1651)

У MongoDB Compass даже откат на какую-то версию его не завел (https://www.reddit.com/r/ManjaroLinux/comments/c42q93/mongodb_compass_stuck_on_loading_screen/)

Studio 3T жирная, страшная и платная.

Остановился на NoSqlBooster

Переписал своего ботика (@music_yandex_bot) на MongoDB, смигрировал данные и чёт так тащусь от этой базы, от работы с mongoengine. Словил некий кайф (возможно это у меня после алхимии такое, а тут всё родное, как в джанго орм).

Наконец-то кто-то открытые соединения хранит в себе сам и можно достучаться по имени откуда угодно. А то таскать объект подключения и заботься о нём надоело. И как бы каждой модели можно указать с какого подключения брать данные и бла-бла, аааай, КАААЙФ.

Аж писать дальше захотелось бота, теперь нормально дату для инлайн сообщений хранить можно будет, ыы.

Конечно чувствую, что не раз еще буду данные мигрировать скриптами... Вот эти все новые поля потом могут понадобиться, дефолтные значения для старых документов.

Больше буду работать - больше разберусь, больше интересных кейсов встречу, больше буду знать и уметь ✨

Чета пролупились глаза. Без SQL БД оказывается так легко жить и наслаждаться. Вообще потерял смысл в РБД как-то. Надо вечерком будет разобраться когда и что юзать (пока только всякие транзакции, роллбэки, консистентность, *забыл умное слово* поддержание актуальности данных с всякими onDelete, onUpdate). Ай блин чета много всего у РБД на самом деле есть. Смысл не потерял, а вот узнать все ещё надо 🙈

UPD. Пока 173 юзера влазит в 62.77КБ. Надо будет подумать над хранением инфы для сообщений, чтоб особо не засирать

Думал никогда не коммитну от своего имени, когда это не надо, нээээт, коммитнул 🌚Нефиг тачки менять (

Ревертнул пока все спят ✨