Идут косяками

Ну и поиск

а толку от них? если поиск по рф, то hh.ru лучше

нуачо, эйчары крутятся, вакансии мутятся

или здесь в jobs

по рф они в телеграме и в линкедине стали активно себя вести

Господа, а есть какие-то лайфхаки для линкедина?

У меня куча хрюш там во френдах

Что с ними делать?

Что с ними делать?

Удалить

Удалить

А если мне работу искать надо будет?

Вообще, я задумывался над тем, чтобы почистить их всех

А если мне работу искать надо будет?

Без них найдёшь

Хм

А если я хочу куда-то за бугром работу искать?

Вопрос к знатокам JOOQ. Пробовал кто генерировать его сущности с xml-ной db? Есть ли возможность этот xml генерировать как-то автоматически, натравив на свою MySQL базу? Пробовал через mysqldump делать експорт структуры. Но полученый xml жуку не подходил. В гугле тоже никакой полезной инфы не нашел.

А если мне работу искать надо будет?

нажмёшь accept на запрос в друзья

нажмёшь accept на запрос в друзья

К кому?

к тебе

Но как ко мне добавятся, если профиль говно?

но сейчас как то добавились

Сложна

Короче. Удалять всех рекрутеров к хуям?

Я сам хз, мне нужен пинок со стороны

чем шире сеть

тем лучше

Так у меня сеть только русско-белорусская

Может заново собирать начать?

Не ну, важный вопрос же

Оставь лучше. Потом сможешь если что крикнуть, мол: -- "свободен, бабоньки, расхватывайте, пока молодой, двести тыщ и я ваш!".

А как лучших то определить?

по аватарке конечно

Да оставь всех. Я удалял только тех, кто больно много в ленту срёт якобы смешными и молодежными зазывами на работу.

+

зачем удалять

линкедин не про удаления же

и илитные контакты

хотя как знать

Ну в теории, там надо пилить сети которые на полмира могут расшириться

А у меня пока не особо

Нужен совет. Есть точки в сети А и Б. Они общаются по HTTP. Нужно, чтобы: - ресурс А отправил не более N запросов/сек на ресурс Б - ресурс Б всегда не получал более N запросов/сек Ресурс А пишем мы, Б сторонний сервис или просто страница сайта. я понимаю как решить первую задачу: ресурс А действительно не сможет честно отправить более N запросов/сек. Но! Нет гарантии, что ресурс Б дествительно всегда будет получать не более N запросов/сек.

если Б получит > N запросов/сек, то он может нас заблочить и этого допускать не стоит. Как быть?

Нужен совет. Есть точки в сети А и Б. Они общаются по HTTP. Нужно, чтобы: - ресурс А отправил не более N запросов/сек на ресурс Б - ресурс Б всегда не получал более N запросов/сек Ресурс А пишем мы, Б сторонний сервис или просто страница сайта. я понимаю как решить первую задачу: ресурс А действительно не сможет честно отправить более N запросов/сек. Но! Нет гарантии, что ресурс Б дествительно всегда будет получать не более N запросов/сек.

Басота, забить на второе и соблюдать это у себя. Фантомных запросов же нет, все твои

проблемы в сети, Луна повернула ось и запросы пришли на Б из прошлого в итоге Б получит > N запросов/сек

как мы можем на это забить?

я пока вижу слать N - m запросов (m сами определяем)

Из какого прошлого о_о ?

пошёл по другой сети, был задержан

если Б получит > N запросов/сек, то он может нас заблочить и этого допускать не стоит. Как быть?

Б в любом случае на уровне сетевого стэка получит > N запросов/сек. Шейпинг надо делать где-то в промежутке, либо дискардить запросы. Можешь просто взять RxJava и не заморачиваться...

...он так то синхронный

...это тебе не посылка на дороге

> Шейпинг надо делать где-то в промежутке, либо дискардить запросы. Можешь просто взять RxJava и не заморачиваться... Про первое не понял, а второе ... причём тут RxJava? Я и на голом JDK написать могу, чтобы А честно отправлял только N запросов/сек и не более

> Шейпинг надо делать где-то в промежутке, либо дискардить запросы. Можешь просто взять RxJava и не заморачиваться... Про первое не понял, а второе ... причём тут RxJava? Я и на голом JDK написать могу, чтобы А честно отправлял только N запросов/сек и не более

Вот, фигарь очередь и не парься

вы предлагаете забить, что Б нас может заблочить?

вы предлагаете забить, что Б нас может заблочить?

Ну на А к примеру сделай от греха при лимите 50 запросов в секунду 45 на всякий случай и вперед.

Запросы по хттп синхронные, они не могут где-то скопиться и приехать скопом

Если запрос обрабатывается Б значит на А в данный момент руками держится соединение. Ну ты понял

я пока вижу слать N - m запросов (m сами определяем)

тоже так думал, но это ведь защита на "авось пронесёт". Решил спросить здесь. Может есть решение лучше.

=)

а Б разве никак не сигнализирует о перегрузке?

ERROR: S client not available

40x кодом, HTTP заголовком, ...

или сразу тупо банит

хай всем

можете помочь не могу установить jdk

плиз хэлп)

Может лучше в FIFA?

в смысле?

я попросил помочь и тут не флуди

если не знаешь

есть кто знает,

?

Убей процесс, начни заново

Ты терпиливый...

В любой непонятной ситуации убивай Java

Убей процесс, начни заново

2,3 сделал все равно так висит

Может в процессах посмотреть нужно

как просмортреть?

Вот они, волшебные бенчмарки)

Когда секурники начинают заниматься перформансом.

Когда секурники начинают заниматься перформансом.

К сожалению, это про меня, дипломированный специалист по КБ, вот, джейсон бенчмаркаю)))

Косяки тут такие что надо выкинуть этот метод и написать 2 нормальных: findMessageByToUser и findMessageByFromUser. Или если действительно важно одним запросом, то переписать его findMessageByUser и сделать просто по юзер_айди.

Мб там ?0 и ?1 надо, а не 1 и 2

тот самый случай когда борешься с фреймворком а не пишешь код

Кароч отличный пример как создать себе проблем из ничего)

Именно

как просмортреть?

диспетчер задач: Ctrl + Alt + Del

Косяки тут такие что надо выкинуть этот метод и написать 2 нормальных: findMessageByToUser и findMessageByFromUser. Или если действительно важно одним запросом, то переписать его findMessageByUser и сделать просто по юзер_айди.

название сути не меняет, в любом случае приходится писать @Query запрос чтоб он нормально отрабатывал, если его не описать он просто не дает собраться проекту