https://github.com/oxfeeefeee/goscript

=) как тебе такое илон маск =)

Ребят, кто-нить знает каналы с вакансиями по C++, C#? Можно что бы не рекламировать просто в ЛС

Банальный совет pro.Cxx  ?

Угу, спасибо Саш

Ща тебе кину кое что )) 😆

Но там через admina

я уже увидел пост, и это нормально совершенно

Интересно , а кто нибудь использует в своих продуктах push подход для доставки данных на клиента. Поделитесь историей ,как вы например от pull пришли к push. Интересно сколько удалось сэкономить в процентах

ну так пуш разный бывает
пуш с гарантированной доставкой
это просто persistent connect (с реконнектом) на клиенте
ну и экономия там в том что ты в user space не лезешь и rtt у тебя тратятся только на keep-alive
все сильно зависит от того сколько коннектов хочется на бокс
в современном железе до 10к коннектов на бокс разницы в ресурсах не увидите
ну разве что сильно в pull напортачите и у вас там будет тратиться адское кол-во ресурсов на то чтобы проверить "а нет ли у нас чего новенького"


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

а при pull ты должен отдельно что нибудь для избегания dog-pile эффекта городить лок какой нибудь чтобы все не побежали читать резко одно сообщение...

в общем и целом пуш требует уметь хотя бы в websocket и со стороны клиента обязательный реконнект
ну и persistence очередь на сервере, red panda, nats.io, kafka гречневая на худой конец =)

Nats  не плох

Привет! Если вы интересуетесь базами данных, у наших друзей есть интересное мероприятие. GridGain R&D дегустация - это интерактивный онлайн-митап, в ходе которого ключевые разработчики Apache Ignite из компании GridGain дадут попробовать свои задачи в онлайн-формате. К участию приглашаются все backend-разработчики: знать Java желательно, но не обязательно.

https://hopin.com/events/gridgain-tasting-12-08

Что вас ждет?
- интерактив: возможность пошевелить мозгами в области темы distributed systems architecture и к тому же ещё и получить приз за это!
- доклад: "Устройство distributed meta storage в Apache Ignite 3.0"
- Q&A session (она же "курилка") с разработчиками GridGain ‒ вопросный безлимит

Когда?
в четверг, 12 августа, в 19:30 по московскому времени

Как повлиять на контент заранее?
Написать в чат https://t.me/joinchat/lARAdOaWJNdiMzRi

Здравствуйте. Если это сообщение будет в рамках этого чата оффтопом, то извините, я действительно не знаю, куда обращаться, так как ранее с такой проблемой не сталкивался. в общем, я пишу веб-сайт, который позволяет следить за историями в Instagram. История — фото или видео, которое исчезает, если его удалить или оно автоматически исчезнет через 24 часа. Я попытался найти такой метод, чтобы можно было получать уведомления о новых историях, но у меня не получилось. У Instagram есть возможность получать уведомления о новых историях, но она не работет, если в истории не упомянуть пользователя. Соответственно, этот способ сразу же отметается. Второй способ — использовать закрытый API, который используется в приложении для мобильных устройств. Истории можно получать сразу нескольких пользователей. Это очень хорошо, однако, возникает пара проблем:
1) Если довольно часто (раз в 5 секунд) делать такой запрос, то чисто в теории Instagram может заблокировать аккаунт за подозрительную активность. Пока такого не было, но Instagram с лёгкостью может отследить, что какой-то клиент делает слишком много однотипных запросов в секунду. Кстати, почему именно один запрос раз в 5 секунд? Ответ прост — пользователь может удалить историю, так что если проверять истории раз в 5 минут, то какие-то истории могут потеряться. Да и назревает проблема расширяемости — что, если нужно следить за 300 пользователей? придётся делать несколько запросов (допустим, максимум можно получить истории у 50 пользователей, тогда надо будет делать 6 запросов), так что это плохо расширяется. Можно, конечно, прокси использовать с другим аккаунтом, но проблема того, что это выглядит подозрительно, остаётся.
Третий способ — можно получить общую информацию об одном пользователе, из которой можно узнать, когда была выложена последняя история. Таким образом, если это время изменилось, то надо получать истории. Этот способ хуже по сравнению с предыдущим, потому что информацию можно получить за один запрос только об одном пользователе.
Четвёртый способ — подписаться на соответствующие аккаунты и получать ленту (один запрос). Да, так можно сделать, однако, есть пользователи, которые банят левые аккаунты, так что вариант с подпиской сразу же отметается.

По итогу остаются два варианта, в котором одинаковый принцип: создать много аккаунтов, с разных IP-адресов делать запросы. Таким образом получится распределить нагрузку по аккаунтам так, что это не будет подозрительно. Правда, на создание аккаунтов придётся немало потратиться, но не суть.

Два вопроса:
1) Исходя из вышеописанной проблемы и способ её решения, как бы вы решили эту проблему?
2) Если создавать много аккаунтов, то лучше для них использовать прокси или что-то другое? (Честно, я слаб в этих ваших распределённых системах. Да, наверное, это даже не является распределённой системой. Я не знаю, можно ли сделать так, что есть основной сервер, который общается с многими более маленькими серверами (получать запрос на получение информации о пользователе от основного сервера, получение информации, выдача этой информации обратно основному серверу — это потребляет не так много ресурсов, поэтому я назвал этот сервер маленьким). Я не знаю терминологию, вообще не разбираюсь в этих вещах, так что сразу хочу попросить прощения за этот текст)

Действительно, не очень по нашей теме вопрос.
А вы с какой целью такой сайт пишете?

Для учебных целей. Если вопрос не по теме, то я дальше продолжу искать информацию об этом

Спасибо за ответ

довольно забавное совпадение, но сегодня днём была выложена статья на хабре по этой теме
https://habr.com/ru/post/571846/

А сталкивался кто-то с Persistent data structure, которые бы вот со стороны стораджа использовались?Вот ссылка на определение таких структур https://en.wikipedia.org/wiki/Persistent_data_structure

Там есть еще статьи  полезные