Например, два телефона показывают друг другу QR-коды, после чего могут обмениваться файлами. Получится что-то типа https://ru.wikipedia.org/wiki/Shareit, только через интернет.
Вообще, необходимость иметь дополнительный канал связи для обмена адресами это проблема. Если хотим удобства, придётся использовать третью сторону для этого. А ей придётся доверять.
Я же правильно понимаю, что если я хочу добавлять в свой уютный чатик кого угодно, то кому-то из чатика придётся руками добавлять каждого нового участника?
В моём уютном мирке бэкенд программистов отдельно взятой компании, получилось, что сеньор - это человек, которому можно доверить задачи уровня проекта. Он сам вытянет нужные знания, пнёт нужных людей (типа аналитика), согласует с заинтересованных лицами (в рамках договорённостей) и доведёт задачу до завершения так, что не придётся переделывать.
Грубо говоря сеньор - это мидл + софт скилы + умение делать проекты.
При старте каждый воркер будет идти в базу и в рамках своего лимита получать список id свободных задач. После этого он будет пытаться назначить эти задачи на себя — по сути, просто делать update-запрос, пытаясь проставить им свой worker_id.
видно, что скорость падает из-за лишней нагрузкой на БД из-за повторения запросов.
А какая у вас БД?
В postgresql можно использовать блокировку на строки + обновление в одном запросе. Тогда не будет перезапросов.
UPDATE
task_table
SET
version = version + 1,
available_after = now() at time zone 'utc' + @lockInterval,
worker_id = @workerId
WHERE
id IN (
SELECT id
FROM task_table
WHERE
(available_after is null OR available_after < now() at time zone 'utc')
AND completed_at is null
ORDER BY id
LIMIT 1000
FOR UPDATE SKIP LOCKED
)
RETURNING *, now() at time zone 'utc' - created_at AS Lifetime
Подзапрос ищет первые 1000 не заблокированных строк, обновление берёт строки в обработку без гонок.
Согласен, JIT убирает проверку, если точно уверен, например, если экземпляр создали через new. Но чаще значение мы получаем из функции или из параметра и для таки переменных проверка всё равно будет, хоть переменная и не nullable.
Я вот что ещё понял: мы обычно сравниваем одни значения с другими и только булы особенные: с ними либо ничего не делают, либо отрицают (C#). Т.е. если увидел булевую переменную в выражении, будь любезен сделай глазами влево, чтоб узнать есть там восклицательный знак или нет (и ты его точно не пропустил).
Если использовать сравнение через `== false` вместо отрицания, то ответ на вопрос, было отрицание или нет, всегда будет находится справа от переменной. Лично мне так оказалось удобнее.
Пишу на C# и у нас на проекте принято соглашение не использовать восклицательный знак, т.к. его не видно. Пишем такую вот, на первый взгляд, странную конструкцию:
Сначала непривычно, но быстро привыкаешь. Ищешь отрицание в конце, а не в начале.
Кроме малозаметности, ещё вижу проблему с отрицаниями через восклицательный знак. Когда последовательно читаешь код, нужно держать в голове это отрицание по доберёшься до того, что отрицаешь.
Не страна.город.мэрия.зачем.так.много.вложенности.удалена //удалена что? а! не удалена
vs
страна.город.мэрия.зачем.так.много.вложенности.удалена отрицаем удаление // теперь не читается как предложение, зато понятно о каком свойстве идёт речь.
Есть такое, но так проще об этом рассуждать. Докинз использовал тот же приём.
Если выражаться корректнее: ген существует потому что копируется, потому что его информация не исчезла. С этой точки зрения, чтобы быть "успешным" геном, достаточно существовать сколько-то значительное время.
Собственно вся жизнь держится на воспроизведении репликаторами самих себя.
Это вообще огромная загадка: зачем мы передаем ДНК, которая по большей части состоит из бесполезного мусора
Докинз в древнем эгоистичном гене писал следующее: задача гена - копировать самого себя. Т.е. мусорная ДНК - это успех генов этой ДНК. Больше никакой причины для её существования не нужно.
В своих проверках IMY [шведский DPA] считает, что данные, переданные в США через инструмент статистики Google, являются личными данными, поскольку данные могут быть связаны с другими уникальными передаваемыми данными. Орган также приходит к выводу, что технические меры безопасности, которые предприняли компании, недостаточны для обеспечения уровня защиты, который по существу соответствует тому, который гарантируется в рамках ЕС/ЕЭЗ
Я здесь: когда ревью проводит равный по опыту - это пир ревью. Аля peer to peer.
В обычных компаниях оно и так почти всегда пир, но в образовательном процессе нужно подчеркнуть, что не только преподаватель проверяет. Видимо им надо.
Для компаний это может звучать так: для джунов у нас сначала пир-ревью, потом уже смотрит ментор. Хотя я считаю, что проще сказать, что джунов сначала ревьюят джуны, а потому уже ментор.
У меня похожие рассуждения, только одной сортировкой не обойтись, ибо нужно на каждом шаге выбирать лучшую карточку. Так же добиваем "нулями", только держим в уме, что нули - это числа из других карточек. Пытаемся найти комбинацию карточек, которые заменяют нули и будут больше кандидата. Если таких нет, то выбираем эту карточку. Сложность кубическая получается.
Осталось только примотать файлообменник!
Например, два телефона показывают друг другу QR-коды, после чего могут обмениваться файлами. Получится что-то типа https://ru.wikipedia.org/wiki/Shareit, только через интернет.
Вообще, необходимость иметь дополнительный канал связи для обмена адресами это проблема. Если хотим удобства, придётся использовать третью сторону для этого. А ей придётся доверять.
Я же правильно понимаю, что если я хочу добавлять в свой уютный чатик кого угодно, то кому-то из чатика придётся руками добавлять каждого нового участника?
В моём уютном мирке бэкенд программистов отдельно взятой компании, получилось, что сеньор - это человек, которому можно доверить задачи уровня проекта. Он сам вытянет нужные знания, пнёт нужных людей (типа аналитика), согласует с заинтересованных лицами (в рамках договорённостей) и доведёт задачу до завершения так, что не придётся переделывать.
Грубо говоря сеньор - это мидл + софт скилы + умение делать проекты.
Что такое BD+CDC?
Видимо не везде так. У нас бэкендер может передоговориться с аналитиком и дизайнером.
А какая у вас БД?
В postgresql можно использовать блокировку на строки + обновление в одном запросе. Тогда не будет перезапросов.
Подзапрос ищет первые 1000 не заблокированных строк, обновление берёт строки в обработку без гонок.
Возвращает само значение. Код на шарпах, но помнится на плюсах можно так же делать.
Можно ещё в условии присваивание и сравнение сразу делать, типа `if((b = a) > 10)`. Но я такое на рефакторинге не пропустил бы.
Да, инлайнер крутой, жаль с объектами из бд и запросов так не может
Согласен, JIT убирает проверку, если точно уверен, например, если экземпляр создали через new. Но чаще значение мы получаем из функции или из параметра и для таки переменных проверка всё равно будет, хоть переменная и не nullable.
Для параметра видно 2 джампа на L0028.
Но это всё экономия на спичках
Мне казалось, что это не общеупотребительная практика. Есть ссылки на массовое применение?
И появляется дополнительная проверка на то, что проект не null. Возникает вопрос: это специально или побочный эффект?
В данном случае я бы не стал пользоваться паттерн матчингом, т.к. проще не становится.
К счастью, нет (:
Я вот что ещё понял: мы обычно сравниваем одни значения с другими и только булы особенные: с ними либо ничего не делают, либо отрицают (C#). Т.е. если увидел булевую переменную в выражении, будь любезен сделай глазами влево, чтоб узнать есть там восклицательный знак или нет (и ты его точно не пропустил).
Если использовать сравнение через `== false` вместо отрицания, то ответ на вопрос, было отрицание или нет, всегда будет находится справа от переменной. Лично мне так оказалось удобнее.
Пишу на C# и у нас на проекте принято соглашение не использовать восклицательный знак, т.к. его не видно. Пишем такую вот, на первый взгляд, странную конструкцию:
Сначала непривычно, но быстро привыкаешь. Ищешь отрицание в конце, а не в начале.
Кроме малозаметности, ещё вижу проблему с отрицаниями через восклицательный знак. Когда последовательно читаешь код, нужно держать в голове это отрицание по доберёшься до того, что отрицаешь.
Не страна.город.мэрия.зачем.так.много.вложенности.удалена //удалена что? а! не удалена
vs
страна.город.мэрия.зачем.так.много.вложенности.удалена отрицаем удаление // теперь не читается как предложение, зато понятно о каком свойстве идёт речь.
А я пишу доки на тесты.
Но у нас много интеграционных тестов на апи и по доке проще понять, какие кейсы уже протестированы. Особенно помогает, если тесты писал не ты.
Есть такое, но так проще об этом рассуждать. Докинз использовал тот же приём.
Если выражаться корректнее: ген существует потому что копируется, потому что его информация не исчезла. С этой точки зрения, чтобы быть "успешным" геном, достаточно существовать сколько-то значительное время.
Собственно вся жизнь держится на воспроизведении репликаторами самих себя.
Докинз в древнем эгоистичном гене писал следующее: задача гена - копировать самого себя. Т.е. мусорная ДНК - это успех генов этой ДНК. Больше никакой причины для её существования не нужно.
Что-нибудь изменилось с тех пор?
Понял, спасибо
Я правильно понимаю, что редису понадобилось в 40 раз больше памяти, или они что-то с этим сделали?
Законы такие
Я здесь: когда ревью проводит равный по опыту - это пир ревью. Аля peer to peer.
В обычных компаниях оно и так почти всегда пир, но в образовательном процессе нужно подчеркнуть, что не только преподаватель проверяет. Видимо им надо.
Для компаний это может звучать так: для джунов у нас сначала пир-ревью, потом уже смотрит ментор. Хотя я считаю, что проще сказать, что джунов сначала ревьюят джуны, а потому уже ментор.
У меня похожие рассуждения, только одной сортировкой не обойтись, ибо нужно на каждом шаге выбирать лучшую карточку. Так же добиваем "нулями", только держим в уме, что нули - это числа из других карточек. Пытаемся найти комбинацию карточек, которые заменяют нули и будут больше кандидата. Если таких нет, то выбираем эту карточку. Сложность кубическая получается.