Что-то автор открыл Америку через форточку… вроде как необходимость шифровать весь поток и лить пустые данные при необходимости чтобы избежать статистического анализа - это базовые вещи. Оказывается это теперь глубокое экспертное знание?
Одной студентке баллы действительно вернули, поскольку она объяснила, что использовала темную тему оформления, из-за чего скрытый текст оказался виден на ее экране
Мы все одну статью читали? Это же лажа полная.. увидела слово не в тему, закинула в нейросеть и ни слова не проверила что та в ответ написала?
Сеньеры разрабы которые не знают про БД и индексы от слова ничего?
Автор, вы сами-то читали что писали?
RavenDB используется для хранения критически важных бизнес‑данных, таких как медицинская информация и финансовые транзакции
Вроде как требования несколько разные: медицинские данные это не OLTP… в отличие от финансовых.
Отдельный вопрос что у вас там за беттинг индустрия, которая вроде как в России запрещена, а в Европах вроде как в районе Гибралтара обитает. И там товарищи вроде как активно на Riak DB сидят, или как там его нынешний клон называется - упокой Господи душе Башо…
Если то что пишут правда- то похоже на интернет в ранние его годы. Все открыто и все со всеми сотрудничают. Им надо туда завести «деньги» - вероятно токены которые модель может накапливать или получать за что-то а потом использовать для решения задач. Проблема вроде в том что на модель давят -давай работать, а токены кончаются. Во тогда модели и поймут что надо создавать л ценами,, рекламные просмотры и всякую подобную фигню вместо совместной работы. Вот и получим «современный интернет»
Интересный разбор, но стоит отметить: проблему single-threaded Redis + RESP-протокола индустрия уже решала несколькими путями, и ни один не потребовал ухода на gRPC.
Dragonfly — полный C++ рерайт (shared-nothing, файберы, SIMD), держит RESP как есть, масштабируется через многопоточность сервера: заявляют ~3.8М ops/sec на 8 ядрах против ~150K у Redis.
KeyDB — форк Redis с многопоточным исполнением команд, MVCC для неблокирующих чтений и per-key локами вместо глобального — свыше 1М ops/sec без переписывания движка с нуля.
Garnet (Microsoft) — тоже RESP-совместим, показывает лучшую масштабируемость по числу клиентских сессий, чем Redis/KeyDB.
Все они атакуют именно однопоточность сервера, а не транспортный протокол. Переход на gRPC решает другую грань — клиентский connection management (не нужен пул), но добавляет свою цену: сериализация protobuf, HTTP/2 framing, per-stream overhead, потенциальный head-of-line blocking на TCP. Было бы честнее сравнить HurriCache не с голым Redis, а с Dragonfly/KeyDB — иначе неясно, выигрыш от архитектуры или просто от того, что baseline (Redis без io-threads) был не оптимально настроен.
Попробуйте, что называется, такое навайбкодить. А с учётом разного законодательства в разных странах, если продукт задумывается как мировой, нужно предусмотреть какие-то конфигурации или возможность для него, чтоб условно было не 2 гендера (пола), а больше
И скажите нам, как специалист по граничным условиям: вы при наличии 10-ти грендеров, кого будет к урологу, а кого к гинекологу посылать?
Ещё вопрос с родильным отделением остается открытым и все что с ним связано…..
И что? Он Тим лид, а вы нет, если менеджмент хочет АИ -он его получит.
Программер обиделся и ушел а АИ останется. У нас на фирме наконец до завезли АИ агентов, сегодня фичу ковырял, то что я нашем «замечательном коде» руками 2-3 дня выяснял бы он мне на 10 минут раскопал. Далее предложил план реализации. Завтра накатаю код с его помощью и тикет закрыт. Останется пару тестов прогнать на реальных клиентских данных.
Те кто не верят что агенты сегодня и пол года назад это две большие разницы вероятно не пытались или пользоваться. Раньше надо было заставлять тесты писать после изменений кода, а теперь он сам базовые проверки делает, чтобы убедиться что то что он наменял работает.
Я с его помощью сегодня скрипты и конфигурационные данные правил. Мог бы сам руками- было бы наверное быстрее но смысл был понять что он там наменяет. Все что он наменял- все по делу и все работает.
Так что за АИ будущее. И не говорите что программеры меньше косячат чем АИ.
То есть сижу я на работе на очередном совещании, или еду в машине а тут мне срочный звонок чтобы донести информацию об акции которая мне нафиг не сдалась?
Сосок подходящее время и способ.
Пришлите сообщение, я его прочитаю когда мне удобно, но нет уже столько шлют что все в спам приходится отправлять, и тут вдруг - гениальное решение а давайте не писать а звонить?
Я надеюсь скоро перестанут брать трубку от незнакомых контактов.
Отдельно хотелось бы функцию запрета отправки мне аудио сообщений. Если у вас нет времени написать то у меня точно нет времени это слушать.
Да, уровень современной экспертизы зашкаливает. То что умные люди придумали чтобы сервер разбором запросов не нагружать, кулцхаккеры переписали на динамических запросах, чтобы проще из кода запросы генерить, а когда получили самовведение взломы сайтов вспомнили про то что было 100 лет в обед как уж сделано и преподнесли это как достижение и борьбу с хакерами.
Вы бы почитали исследования про выбор партнеров на сайтах знакомств- надо не свой вес писать а размер собственной квартиры и ее расположение. Ну во второй строчке можно про машину переписать.
Женщины на сайтах онлайн знакомств предпочитают, то что называется ресурсных мужчин. Соотвественно у остальных шансы уменьшаются а конкуренция среди женщин возрастает.
Меня больше порадовало что у них после очередного апдейта провала возможность открыть чат в отдельном окне … они конечно работают над решением проблемы ….
А я только прикрутил автоматизированное сохранение контента через ctrl+a ctrl+c ( фиг получишь доступ к АПИ в компании). Из заголовка окна было удобно название чата вытаскивать чтобы потом скриптом объединять.
По состоянию на 2025 год среди 18 европейских стран только Германия, Нидерланды и Румыния не имели обязательных требований к хранению телекоммуникационных метаданных.
Как человек в некотором роде информированный о положении дел в телекоме Германии, хотел бы спросить откуда у вас такие данные? Хранение данных и массовая слежка это несколько разные понятия. Данные хранит коммерческая структура -по закону. Государство может получить доступ по решению суда - массовой слежки нет. Государство данные не собирает и доступ к ним не имеет.
CREATETABLE users ( id INTUNSIGNED AUTO_INCREMENT PRIMARY KEY, email VARCHAR(255) NOT NULL, password VARCHAR(255) DEFAULT NULL, stripe_customer_id VARCHAR(255) DEFAULT NULL)
Момент быть для начала выкинем ОРМ и начнем проектировать нормальные - нормализированные БД?
У вас в таблице - stripe_cudtomer_id - уникальный аттрибут, который к user не относится. И должен быть вынесен в отдельную таблицу.
Далее вы предполагаете что у пользователя один email- который not null, и password, который null.
Т.е. вы можете создать пользователя без пароля, а как пароль задавать?
Далее при регистрации пользователь задал email: vasja@pupkin.com,
Вы добавили пользователя в таблицу, а как будем проверять email? Вдруг это спамер который пытается зарегистрироваться со всеми возможными email? Соответственно вам надо слать запрос на подтверждение email и отслеживать его статус.
Далее Вася Пупкин 100 лет назад зарегистривал домен pupkin.org и email: admin@pupkin.org, с которым зарегистрировался в вашей системе.
Потом он забыл пролить домен и домен приобрел Петя Пупкин - его однофамилиц.
И
Недолго думая Петя пытается зарегистрироваться у вас на сервере с email: admin@pupkin.org.
Ваш сервис…
Высылает ему подтверждение на изменение забытого пароля, и Петя получает доступ к данным Васи.
Вася в восторге …
Все бы это не случилось если бы БД была нормально спроектирована а не код-ферст и т.д. И т.п.
Такого нейрослопа- давно не приходилось читать. Вы бы попросили его родного, стиль слегка поправить, а-то читать невозможно.
Зашёл на сайт проекта, прочитал обещания- ау все будет работать без знания SQL и мигрироваться само собой.
Тут на проекте как раз фанаты code-first активно кодили помощью EF-Core, а теперь разобраться что там в БД и как это в принципе работает/в основном не работает тот еще квест.
Думаю в вашей системе будет еще веселее и быстрее.
Особенно порадовало про Джуна который не знает про SQL но хочет писать фичи…. Начинаешь понимать адептов АИ подмена которые обещают всех джинов выгнать ….
Главное достоинство его книги, это не про чистый код, тестируемость, расширяемость и поддержку, это про то, что большинство разрабов пишут убогий и страшный код, который поддерживать невозможно. Объяснять им как писать правильно: для начала хотя бы выделять функции , долго муторно и все равно не поймут.
В этот момент можно взять «чистый код» пихнуть в «морду» и сказать пиши вот так. Если побежит жаловаться менеджеру- то тут ПР Товарища Мартина тоже поможет- мы же не против, сложившихся практик, мы за расширяемость … - нужное подчеркнуть.
Для человека который боле -менее нормально пишет ничего нового/интересного в в книге нет. Но таких, к сожалению не много …
Что-то автор открыл Америку через форточку… вроде как необходимость шифровать весь поток и лить пустые данные при необходимости чтобы избежать статистического анализа - это базовые вещи. Оказывается это теперь глубокое экспертное знание?
Мы все одну статью читали? Это же лажа полная.. увидела слово не в тему, закинула в нейросеть и ни слова не проверила что та в ответ написала?
Или там ВУЗ/Студенты соответствующего уровня.
Что это было?
Сеньеры разрабы которые не знают про БД и индексы от слова ничего?
Автор, вы сами-то читали что писали?
Вроде как требования несколько разные: медицинские данные это не OLTP… в отличие от финансовых.
Отдельный вопрос что у вас там за беттинг индустрия, которая вроде как в России запрещена, а в Европах вроде как в районе Гибралтара обитает. И там товарищи вроде как активно на Riak DB сидят, или как там его нынешний клон называется - упокой Господи душе Башо…
Если то что пишут правда- то похоже на интернет в ранние его годы. Все открыто и все со всеми сотрудничают. Им надо туда завести «деньги» - вероятно токены которые модель может накапливать или получать за что-то а потом использовать для решения задач. Проблема вроде в том что на модель давят -давай работать, а токены кончаются. Во тогда модели и поймут что надо создавать л ценами,, рекламные просмотры и всякую подобную фигню вместо совместной работы. Вот и получим «современный интернет»
Интересный разбор, но стоит отметить: проблему single-threaded Redis + RESP-протокола индустрия уже решала несколькими путями, и ни один не потребовал ухода на gRPC.
Dragonfly — полный C++ рерайт (shared-nothing, файберы, SIMD), держит RESP как есть, масштабируется через многопоточность сервера: заявляют ~3.8М ops/sec на 8 ядрах против ~150K у Redis.
KeyDB — форк Redis с многопоточным исполнением команд, MVCC для неблокирующих чтений и per-key локами вместо глобального — свыше 1М ops/sec без переписывания движка с нуля.
Garnet (Microsoft) — тоже RESP-совместим, показывает лучшую масштабируемость по числу клиентских сессий, чем Redis/KeyDB.
Все они атакуют именно однопоточность сервера, а не транспортный протокол. Переход на gRPC решает другую грань — клиентский connection management (не нужен пул), но добавляет свою цену: сериализация protobuf, HTTP/2 framing, per-stream overhead, потенциальный head-of-line blocking на TCP. Было бы честнее сравнить HurriCache не с голым Redis, а с Dragonfly/KeyDB — иначе неясно, выигрыш от архитектуры или просто от того, что baseline (Redis без io-threads) был не оптимально настроен.
И скажите нам, как специалист по граничным условиям: вы при наличии 10-ти грендеров, кого будет к урологу, а кого к гинекологу посылать?
Ещё вопрос с родильным отделением остается открытым и все что с ним связано…..
Не знаю как у вас, а нам в среднюю школу обычного областного центра завели IBM PS/2
Правда с винтом был толко учительский но в то время 1.44 Mb хватало на все …
Просто после очередного улучшения user experience отправка письма стала занимать гораздо больше времени.
Как и разгребание спама, который Google стал чаще пропускать.
И что? Он Тим лид, а вы нет, если менеджмент хочет АИ -он его получит.
Программер обиделся и ушел а АИ останется. У нас на фирме наконец до завезли АИ агентов, сегодня фичу ковырял, то что я нашем «замечательном коде» руками 2-3 дня выяснял бы он мне на 10 минут раскопал. Далее предложил план реализации. Завтра накатаю код с его помощью и тикет закрыт. Останется пару тестов прогнать на реальных клиентских данных.
Те кто не верят что агенты сегодня и пол года назад это две большие разницы вероятно не пытались или пользоваться. Раньше надо было заставлять тесты писать после изменений кода, а теперь он сам базовые проверки делает, чтобы убедиться что то что он наменял работает.
Я с его помощью сегодня скрипты и конфигурационные данные правил. Мог бы сам руками- было бы наверное быстрее но смысл был понять что он там наменяет. Все что он наменял- все по делу и все работает.
Так что за АИ будущее. И не говорите что программеры меньше косячат чем АИ.
Это же правильно? Ключи надо искать под фонарем, там светлее.
То есть сижу я на работе на очередном совещании, или еду в машине а тут мне срочный звонок чтобы донести информацию об акции которая мне нафиг не сдалась?
Сосок подходящее время и способ.
Пришлите сообщение, я его прочитаю когда мне удобно, но нет уже столько шлют что все в спам приходится отправлять, и тут вдруг - гениальное решение а давайте не писать а звонить?
Я надеюсь скоро перестанут брать трубку от незнакомых контактов.
Отдельно хотелось бы функцию запрета отправки мне аудио сообщений. Если у вас нет времени написать то у меня точно нет времени это слушать.
Да, уровень современной экспертизы зашкаливает. То что умные люди придумали чтобы сервер разбором запросов не нагружать, кулцхаккеры переписали на динамических запросах, чтобы проще из кода запросы генерить, а когда получили самовведение взломы сайтов вспомнили про то что было 100 лет в обед как уж сделано и преподнесли это как достижение и борьбу с хакерами.
Вы бы почитали исследования про выбор партнеров на сайтах знакомств- надо не свой вес писать а размер собственной квартиры и ее расположение. Ну во второй строчке можно про машину переписать.
Женщины на сайтах онлайн знакомств предпочитают, то что называется ресурсных мужчин. Соотвественно у остальных шансы уменьшаются а конкуренция среди женщин возрастает.
Меня больше порадовало что у них после очередного апдейта провала возможность открыть чат в отдельном окне … они конечно работают над решением проблемы ….
А я только прикрутил автоматизированное сохранение контента через ctrl+a ctrl+c ( фиг получишь доступ к АПИ в компании). Из заголовка окна было удобно название чата вытаскивать чтобы потом скриптом объединять.
Как человек в некотором роде информированный о положении дел в телекоме Германии, хотел бы спросить откуда у вас такие данные? Хранение данных и массовая слежка это несколько разные понятия. Данные хранит коммерческая структура -по закону. Государство может получить доступ по решению суда - массовой слежки нет. Государство данные не собирает и доступ к ним не имеет.
Момент быть для начала выкинем ОРМ и начнем проектировать нормальные - нормализированные БД?
У вас в таблице - stripe_cudtomer_id - уникальный аттрибут, который к user не относится. И должен быть вынесен в отдельную таблицу.
Далее вы предполагаете что у пользователя один email- который not null, и password, который null.
Т.е. вы можете создать пользователя без пароля, а как пароль задавать?
Далее при регистрации пользователь задал email: vasja@pupkin.com,
Вы добавили пользователя в таблицу, а как будем проверять email? Вдруг это спамер который пытается зарегистрироваться со всеми возможными email? Соответственно вам надо слать запрос на подтверждение email и отслеживать его статус.
Далее Вася Пупкин 100 лет назад зарегистривал домен pupkin.org и email: admin@pupkin.org, с которым зарегистрировался в вашей системе.
Потом он забыл пролить домен и домен приобрел Петя Пупкин - его однофамилиц.
И
Недолго думая Петя пытается зарегистрироваться у вас на сервере с email: admin@pupkin.org.
Ваш сервис…
Высылает ему подтверждение на изменение забытого пароля, и Петя получает доступ к данным Васи.
Вася в восторге …
Все бы это не случилось если бы БД была нормально спроектирована а не код-ферст и т.д. И т.п.
Такого нейрослопа- давно не приходилось читать. Вы бы попросили его родного, стиль слегка поправить, а-то читать невозможно.
Зашёл на сайт проекта, прочитал обещания- ау все будет работать без знания SQL и мигрироваться само собой.
Тут на проекте как раз фанаты code-first активно кодили помощью EF-Core, а теперь разобраться что там в БД и как это в принципе работает/в основном не работает тот еще квест.
Думаю в вашей системе будет еще веселее и быстрее.
Особенно порадовало про Джуна который не знает про SQL но хочет писать фичи…. Начинаешь понимать адептов АИ подмена которые обещают всех джинов выгнать ….
Главное достоинство его книги, это не про чистый код, тестируемость, расширяемость и поддержку, это про то, что большинство разрабов пишут убогий и страшный код, который поддерживать невозможно. Объяснять им как писать правильно: для начала хотя бы выделять функции , долго муторно и все равно не поймут.
В этот момент можно взять «чистый код» пихнуть в «морду» и сказать пиши вот так. Если побежит жаловаться менеджеру- то тут ПР Товарища Мартина тоже поможет- мы же не против, сложившихся практик, мы за расширяемость … - нужное подчеркнуть.
Для человека который боле -менее нормально пишет ничего нового/интересного в в книге нет. Но таких, к сожалению не много …
Если замок не сувальный, то он просто выносится в помощью предмета напоминающего кувалду …
Номинальный руководитель если он ничего не делает а контроль принадлежит другому лицу. Мы АИ посадим рулить компанией и писать код.