Программирование[9]

Nikki Sixx написал 4 часа назад:

Как ты заебал блять

149$/ч (+ ещё 149$ персонально для тебя) и я провожу скайп семинар по поиску в шторме

Проведу то же самое за сотку, можешь попросить на работе курсы оплатить

Жужа, ты не находишь странным, что проблемы с поиском только у тебя?

каждый раз когда работаю с документами (а на тимлидской позиции это довольно таки часто)

и вижу что менеджеры/секретари/аналитики/hr`ы и прочий нетехнический сброд контингент

используют для контроля версионирования:

- имя файла ("Документ - Руководство пользователя v3.10 от 20.01.2020")

- либо режим рецензий (дифф с предыдущей версией через рецензии делается)

- либо полный перечень изменений в конце документа в виде таблицы

- либо что-то типа гуглдока / страниц в конфлюенс где каждое изменение автоматически фиксируется в новую версию (изменение пробела - новая версия, также нет понятия ветвления или применения группы изменений не через кривой режим рецензирования)

то у меня подгорает. я не понимаю почему еще не изобрели "гит для ворда" ?????

какого хуя???

я уверен что там конечно есть ряд нюансов, связанный с форматированием и всем прочим, но 100% они все решаются

и насколько бы всем стало удобнее

вообще есть подозрение что подобное уже есть, просто никто о нем почему-то не знает в моем окружении...

кто прочитал тот сифа

у нас на проекте разработчики ругаются на конфлюэнс и просят тз вести в маркдауне в гитлабе, тем более там есть веб ide и предпросмотр

Just.Doit написал 58 минут назад:

каждый раз когда работаю с документами (а на тимлидской позиции это довольно таки часто)

и вижу что менеджеры/секретари/аналитики/hr`ы и прочий нетехнический сброд контингент

используют для контроля версионирования:

- имя файла ("Документ - Руководство пользователя v3.10 от 20.01.2020")

- либо режим рецензий (дифф с предыдущей версией через рецензии делается)

- либо полный перечень изменений в конце документа в виде таблицы

- либо что-то типа гуглдока / страниц в конфлюенс где каждое изменение автоматически фиксируется в новую версию (изменение пробела - новая версия, также нет понятия ветвления или применения группы изменений не через кривой режим рецензирования)

 

то у меня подгорает. я не понимаю почему еще не изобрели "гит для ворда" ?????

какого хуя???

я уверен что там конечно есть ряд нюансов, связанный с форматированием и всем прочим, но 100% они все решаются

и насколько бы всем стало удобнее

вообще есть подозрение что подобное уже есть, просто никто о нем почему-то не знает в моем окружении...

 

версионирование документов давно уже есть, проблема в документообороте и юридических мутках

nobodies написал 2 минуты назад:

версионирование документов давно уже есть, проблема в документообороте и юридических мутках

где как куда? почему все не используют?

какие конкретно инструменты/технологии?

madvlaydin написал 3 минуты назад:

у нас на проекте разработчики ругаются на конфлюэнс и просят тз вести в маркдауне в гитлабе, тем более там есть веб ide и предпросмотр

вот это кстати крутая идея

в конфлуенсе есть история изменений нормальная и история старых версий

на кой хуй тебе блядь в конфлуенсе разные ветки изменений, я вообще ни 1 практического кейса придумать не могу

ну например у тебя есть 3 разных варианта изменений требований/документации. которые довольно массивные и могут длится месяцами, а финально войти в документацию должны в момент залития на прод - ну как с ветками кароче

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

и проблема если у тебя по одному блоку идут 2 параллельных разработки. тогда не понятно какой диф к какой разработке относится

вообще любой кейс такой же как и в разработке - параллельные изменения которые в разные моменты времени могут быть применены.

с точки зрения svn тебе тоже ветки не нужны. а раньше вообще архивчики складывали в подписанные версияи папочки и вообще гит не нужон был

вообще разницы между документацией (какой либо) и кодом особо быть не должно - это практически одно и то же. текст с форматированием.

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

и для бухгалтеров еще ок

но когда ты в ит компании - в чем проблема то

Lotus написал 14 минут назад:

в конфлуенсе есть история изменений нормальная и история старых версий

на кой хуй тебе блядь в конфлуенсе разные ветки изменений, я вообще ни 1 практического кейса придумать не могу

ну вот ты разработчик, у тебя есть ide, которая умеет маркдаун показывать нормально

клонируешь репозиторий с тз-шками, видишь историю изменений, видишь дельту наглядно

а в конфлюэнсе тебе надо туда зайти, найти документ, нажать опции, выбрать предыдущую версию и нажать сравнить с текущей, и сидеть высматривать изменения

+ аналитик пишет тз по сути на сервере, сеть отвалились - ггвп

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

Just.Doit написал 39 минут назад:

ну например у тебя есть 3 разных варианта изменений требований/документации. которые довольно массивные и могут длится месяцами, а финально войти в документацию должны в момент залития на прод - ну как с ветками кароче

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

и проблема если у тебя по одному блоку идут 2 параллельных разработки. тогда не понятно какой диф к какой разработке относится

чел, ты ....

Вместо того что бы заниматься решением проблем сумасшедших просто создай 2 странички на конфлюенсе v1 и v2

Хотите задачу?

Есть итерируемая колекция упорядоченная по мере добавления (например посты этого топика).

В коллекции лежат сущности (посты) у которых есть какой-то ключ. (например имя пользователя).

Задача разбить коллекцию на батчи. В каждом батче лежит не более одного сообщения от каждого из пользователей.

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

Пример.

[А-1,Б-1,В-1,Б-2,В-2,Г-1,Б-3,А-2,Г-2,А-3] - где имя ключ число время+payload для наглядности

Разбиваются на

[А-1,Б-1,В-1], [Б-2,В-2,Г-1], [Б-3,А-2,Г-2], [А-3]

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

Но можно разбить более эффективно.

[А-1,Б-1,В-1,Г-1], [Б-2,В-2,Г-2], [Б-3,А-3]

Вот собственно задача как это сделать изящно, функционально, чтобы батчи были максимально объемные, их было как можно меньше, но все это не превышая O(n) и без больших объемов памяти.

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

Естественно число ключей и их диапазон не известен заранее.

А да, забыл ключевое.

Можно отбросить те данные для которых есть ключи в поздних батчах. Это если работа на конечной коллекции.

tl:dr это все сводится к тому, что

UPSERT INTO xxx (key,value) VALUES

(...),

(...),

(...),

(...),

(...);

Захлебывается если в списке дублируется одинаковый PK констрейнт.

UPSERT INTO xxx (key,value) VALUES

(...),

(...);

UPSERT INTO xxx (key,value) VALUES

(...),

(...),

(...);

Отработает нормально, если их разнести.

Нужно по сути в бд занести самый последний payload на ключ.

Index написал 7 минут назад:

Хотите задачу?

Есть итерируемая колекция упорядоченная по мере добавления (например посты этого топика).

В коллекции лежат сущности (посты) у которых есть какой-то ключ. (например имя пользователя).

Задача разбить коллекцию на батчи. В каждом батче лежит не более одного сообщения от каждого из пользователей.

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

Пример.

[А-1,Б-1,В-1,Б-2,В-2,Г-1,Б-3,А-2,Г-2,А-3] - где имя ключ число время+payload для наглядности

Разбиваются на

[А-1,Б-1,В-1], [Б-2,В-2,Г-1], [Б-3,А-2,Г-2], [А-3]

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

Но можно разбить более эффективно.

[А-1,Б-1,В-1,Г-1], [Б-2,В-2,Г-2], [Б-3,А-3]

 

Вот собственно задача как это сделать изящно, функционально, чтобы батчи были максимально объемные, их было как можно меньше, но все это не превышая O(n) и без больших объемов памяти.

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

 

Естественно число ключей и их диапазон не известен заранее.

если идти с конца то будет

[А-1,Б-1,В-1,Б-2,В-2,Г-1,Б-3,А-2,Г-2,А-3] => [А-3,Г-2,Б-3,В-2], [А-2,Г-1,Б-2,В-1], [Б-1,А-1]

Так ты сам нарисовал уже

1,2,3 - мап словарь етц хэш таблица

При добавлении нового поста смотришь 1, если нет ключа добавляешь, если есть смотришь следующий, если не нашел добавляешь новый

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

Сложность у тебя будет от O(1) (чекнуть первую таблицу и убедится что там нихуя нет), до O(n) когда все посты срет один пользователей и только он.

Но только зачем тебе такая упаковка? Цель какая?

Index написал 19 минут назад:

где имя ключ число время

можно по-русски?

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

ну дальше стрим тогда редьюсишь (currentPost, accum) =>

где accum - это текущие батчи в процессе формирования. это объекты содержащие хешсет с вхождениями имен, размер батча и саму коллекцию батча. т.е. нечто вроде List[(NameEntriesSet, Size, BatchCollection)]

среди них ищешь наименее наполненный и спрашиваешь в каком не было текущего вхождения (через Set), если таковых нет - то примерно как и сейчас создаешь новый с этим вхождением

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

Сам спросил, сам решил.

            final Collection<ProfileEntity> distinct = StreamEx.of(profiles)
                                                           .groupingBy(AbstractEntity::getUserId, Collectors.reducing(null, (ignored, latest) -> latest))
                                                           .values();

По сути что мне надо, так это distinctLatest но такого механизма нет, пришлось делать самому.

на стриме не отработает, но и похуй, у меня пока что коллекция. Сколько оно памяти сожрет когда сверху придет коллекция на сотни МБ хуй знает тоже 

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

GoldRobot написал Только что:

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

 

Еп 

Хотя блять, все таки возможно придется возвращаться к задаче разбиения на батчи, если будет сложная логика в ON DUPLICATE UPDATE 

кто-нибудь объясните мне что значит "имя ключ число время"

мой русский таких фраз не позволяет без знаков препинания