This media is not supported in your browser
VIEW IN TELEGRAM
Datadog, CoScreen, парное программирование.
Datadog, на которых я наткнулся, пока искал альтернативы GigaCode и Tabnine, помимо того, что приобрели Codiga, оказалось что имеют так-же очень крутой проект, являющийся альтернативой Code With Me. В общем программой для совместного кодинга, там можно рисовать, имитировать ввод, расшаривать разные конкретные окна, работая вместе одновременно до 10 человек, без прерывания расшаривания, т.е. разные люди одновременно могут расшаривать свои окна, и все могут работать сразу с разными окнами разных людей — это очень круто, аналогов еще не видел. Кроме тогои имеет стандартный набор для конференций — рисовалки, видео с камеры, звук с микрофона.
Ну и да, проект называется CoScreen, и вау, он бесплатный и работает очень даже неплохо.
https://www.coscreen.co/
Datadog, на которых я наткнулся, пока искал альтернативы GigaCode и Tabnine, помимо того, что приобрели Codiga, оказалось что имеют так-же очень крутой проект, являющийся альтернативой Code With Me. В общем программой для совместного кодинга, там можно рисовать, имитировать ввод, расшаривать разные конкретные окна, работая вместе одновременно до 10 человек, без прерывания расшаривания, т.е. разные люди одновременно могут расшаривать свои окна, и все могут работать сразу с разными окнами разных людей — это очень круто, аналогов еще не видел. Кроме тогои имеет стандартный набор для конференций — рисовалки, видео с камеры, звук с микрофона.
Ну и да, проект называется CoScreen, и вау, он бесплатный и работает очень даже неплохо.
https://www.coscreen.co/
Не ИИ а ЦИМ.
В результате наблюдений:
- за развитием ИИ-лихорадки
- за спросом на ML специалистов
- за внедрением нейросетей в организациях
Сделал вывод, что нейросети превращаются в Централизованный Искусственный Мозг организаций. Не только большие, но и малые организации всё больше заходят в эту волну. ИИ в этих организациях начинает играть роль центра принятия решений, так как все чаще начинает мелькать схема "Все имеющиеся данные организации📄 " ➡️ "ИИ 🤖" ➡️ "Решение 💡 ".
И это на примере любой организации. Банк? Пожалуйста:
🔵 "Выдать ли кредит?"
📄 "Данные о заемщике (открытые/закрытые/государственные) + данные о рынке + данные о состоянии банка + данные о геополитике"
➡️ "ИИ: пара минут вычислений, оценка надежности заемщика и стабильности обстановки в мире, оценка возможностей организации, оценка рисков"
➡️ "👍 🙅 Решение: да/нет".
То, на что раньше уходило множество человеко-часов, теперь решается за пару минут, с гораздо меньшими рисками и гораздо более высокой точностью. Все что нужно — много денег, отдел специалистов, вычислительные мощности. Да, очень дорого, но очень точно и очень перспективно.
Еще примеры:
🔵 "Запускать ли новый продукт?":
📄 "Данные о потребительских предпочтениях + данные о трендах на рынке + данные о продажах конкурентов + производственные мощности"
➡️ "🖥 ИИ: пара минут вычислений, оценка потенциального спроса, прогноз окупаемости, анализ конкурентной среды и сезонных факторов"
➡️ "👍 🙅 Решение: запускать/не запускать продукт"
🔵 "Стоит ли запускать производство мерча по фильму?"
📄 "Данные о ранних отзывах на фильм + анализ трендов в соцсетях + данные о похожих успешных фильмах + прогнозируемая аудитория по возрастам и регионам"
➡️ "🖥 ИИ: пара минут вычислений, оценка спроса, прогноз популярности фильма, анализ возможных регионов для запуска мерча"
➡️ "👍 🙅 Решение: запускать/не запускать мерч, объем и ассортимент"
🔵 "Стоит ли продолжать рекламную кампанию?"
📄 "Текущие показатели вовлеченности (CTR, лайки, репосты) + исторические данные по успешным кампаниям + данные о характеристиках аудитории + затраты на рекламу"
➡️ "🖥 ИИ: пара минут вычислений, анализ эффективности, прогноз ожидаемой отдачи, сравнение с предыдущими кампаниями"
➡️ "👍 🙅 Решение: продолжать/остановить кампанию, изменить целевую аудиторию и бюджет"
В результате наблюдений:
- за развитием ИИ-лихорадки
- за спросом на ML специалистов
- за внедрением нейросетей в организациях
Сделал вывод, что нейросети превращаются в Централизованный Искусственный Мозг организаций. Не только большие, но и малые организации всё больше заходят в эту волну. ИИ в этих организациях начинает играть роль центра принятия решений, так как все чаще начинает мелькать схема "Все имеющиеся данные организации
И это на примере любой организации. Банк? Пожалуйста:
То, на что раньше уходило множество человеко-часов, теперь решается за пару минут, с гораздо меньшими рисками и гораздо более высокой точностью. Все что нужно — много денег, отдел специалистов, вычислительные мощности. Да, очень дорого, но очень точно и очень перспективно.
Еще примеры:
Please open Telegram to view this post
VIEW IN TELEGRAM
Минорные коммиты.
Мне очень лень наполнять смыслом сообщения коммитов, которые еще не содержат какого-либо результата и являются либо коммитом просто для персистенции или стэша. Обычно в таких коммитах я ставлю либо +++ либо пишу stash. Потому что он, как отдельно взятый, не будет нести какой-либо ценности, а только в купе с остальными коммитами в фича ветке. Предпочитаю просто сквошить коммиты при слиянии с веткой разработки. Тогда и можно наполнить сообщение коммита смыслом. Хотя для отслеживающих MR/PR сложно понять что изменилось с последнего просмотра.
Очень жду плагин, который будет составлять описание коммита автоматически.
В целом GigaCode уже может делать это через чат, если попросить его, добавив изменения как Patch из гита. (Пример на скринах). Но это все еще не эффективно, потому что при изменении нескольких тысяч строк, патч становится просто гигантским, и нейронка уже отказывается работать.
Мне очень лень наполнять смыслом сообщения коммитов, которые еще не содержат какого-либо результата и являются либо коммитом просто для персистенции или стэша. Обычно в таких коммитах я ставлю либо +++ либо пишу stash. Потому что он, как отдельно взятый, не будет нести какой-либо ценности, а только в купе с остальными коммитами в фича ветке. Предпочитаю просто сквошить коммиты при слиянии с веткой разработки. Тогда и можно наполнить сообщение коммита смыслом. Хотя для отслеживающих MR/PR сложно понять что изменилось с последнего просмотра.
Очень жду плагин, который будет составлять описание коммита автоматически.
В целом GigaCode уже может делать это через чат, если попросить его, добавив изменения как Patch из гита. (Пример на скринах). Но это все еще не эффективно, потому что при изменении нескольких тысяч строк, патч становится просто гигантским, и нейронка уже отказывается работать.
🔥1
Согласен, поэтому давно пересел на яндекс.диск и гружу все фото с телефона туда. Но что будет с телефонами на андроид и приложениями? Уже сейчас множество приложений не принимают оплату. Или простым и доступным OAuth по гугл учетке практически на любом сайте? Стоит ли беспокоиться разработчикам kotlin? Вопросы, ответы на которые никто не знает, кроме того что "время покажет". Но можно сокращать риски и начинать готовиться :D
Forwarded from Бэкдор
Эксперты уверены, что такой штраф платить никто не будет. Тогда у РКН будет легитимный повод просто обрезать Гуглу работу в стране, а у самого Гугла — закрыть регистрацию по русскому номеру.
Чебурнет не за горами.
Please open Telegram to view this post
VIEW IN TELEGRAM
😢1
Сборщик мусора в .NET Core автоматически управляет выделением и освобождением памяти в приложениях ASP.NET Core, освобождая разработчиков от необходимости вручную управлять памятью. Но очистка неуправляемых объектов требует ресурсов процессора, поэтому нужно уменьшить количество и объем выделения объектов.
Особенно затратной является сборка мусора для больших объектов размером более 85 000 байт, которые требуют полной сборки мусора второго поколения. В отличие от коллекций первого и нулевого поколения, для коллекции второго поколения может требоваться временная приостановка выполнения приложения. Частое выделение и освобождение больших объектов может привести к проблемам с производительностью.
Для предотвращения дорогостоящих операций выделения нужно:
— Кэшировать часто используемые большие объекты.
— Использовать буферы пула с помощью ArrayPool для хранения больших массивов.
— Избегать выделения множества коротких больших объектов в критических участках кода.
Проблемы с памятью можно диагностировать, проанализировав статистику сборки мусора (GC) любым доступным инструментом мониторинга и проверив:
— Время приостановки сборки мусора.
— Процент времени процессора, затраченного на сборку мусора.
— Количество поколений 0, 1 и 2.
Особенно затратной является сборка мусора для больших объектов размером более 85 000 байт, которые требуют полной сборки мусора второго поколения. В отличие от коллекций первого и нулевого поколения, для коллекции второго поколения может требоваться временная приостановка выполнения приложения. Частое выделение и освобождение больших объектов может привести к проблемам с производительностью.
Для предотвращения дорогостоящих операций выделения нужно:
— Кэшировать часто используемые большие объекты.
— Использовать буферы пула с помощью ArrayPool для хранения больших массивов.
— Избегать выделения множества коротких больших объектов в критических участках кода.
Проблемы с памятью можно диагностировать, проанализировав статистику сборки мусора (GC) любым доступным инструментом мониторинга и проверив:
— Время приостановки сборки мусора.
— Процент времени процессора, затраченного на сборку мусора.
— Количество поколений 0, 1 и 2.
Пустая трата времени.
Пытаюсь найти хоть одну статью, написанную настоящим человеком, хотя бы чуть чуть разобравшегося в теме.
Сколько процентов от этого текста написан не нейросетью? Эти узнаваемые общие слова, обтекаемые фразы. Сколько времени потрачу на то, чтобы найти нормальную статью, и найду ли вообще. Процент мусорных текстов невероятно возрос из-за Chatgpt. Поэтому считаю, что в ближайшее пару лет сильно возрастет ценность приватных бложиков, где есть только один, близкий к аудитории эксперт в своей области. А всякие печатные станки в виде шлако-сайтов загнутся из-за потери доверия. Сейчас конечно им удается перехватывать некий трафик из-за ключевых слов, но читая статьи, я скорее всего в дальнейшем буду стараться наоборот избегать этот источник. Получается, что и гугл с Яндексом загнутся, если не переквалифицируются с поиска по всем сайтам, на поиск в блогах, с индексом проверки на наличие нейросетей и достоверность информации.
Пытаюсь найти хоть одну статью, написанную настоящим человеком, хотя бы чуть чуть разобравшегося в теме.
В условиях санкций и ограничений выбор между Android и iOS становится еще более сложным. Пользователям следует учитывать не только технические характеристики и предпочтения, но и возможность долгосрочной поддержки устройства в сложившихся условиях.
В конечном итоге, выбор между Android и iOS в 2024 году будет зависеть от ваших личных потребностей, бюджета и предпочтений, а также от внешних факторов, таких как доступность устройств и санкционные ограничения.
Сколько процентов от этого текста написан не нейросетью? Эти узнаваемые общие слова, обтекаемые фразы. Сколько времени потрачу на то, чтобы найти нормальную статью, и найду ли вообще. Процент мусорных текстов невероятно возрос из-за Chatgpt. Поэтому считаю, что в ближайшее пару лет сильно возрастет ценность приватных бложиков, где есть только один, близкий к аудитории эксперт в своей области. А всякие печатные станки в виде шлако-сайтов загнутся из-за потери доверия. Сейчас конечно им удается перехватывать некий трафик из-за ключевых слов, но читая статьи, я скорее всего в дальнейшем буду стараться наоборот избегать этот источник. Получается, что и гугл с Яндексом загнутся, если не переквалифицируются с поиска по всем сайтам, на поиск в блогах, с индексом проверки на наличие нейросетей и достоверность информации.
Леонид Павлов. "It specialist's tricks"
Сборщик мусора в .NET Core автоматически управляет выделением и освобождением памяти в приложениях ASP.NET Core, освобождая разработчиков от необходимости вручную управлять памятью. Но очистка неуправляемых объектов требует ресурсов процессора, поэтому нужно…
Поднимая вопрос о производительности и оптимизации большого объема данных, могу посоветовать следующие способы оптимизации выдачи API (мыслю конечно в контексте dotnet):
0) GraphQL
Понятно, почему я против того, чтобы фронт решал какие данные из БД ему нужны, и как страдает (исчезает) от этого слой бизнес логики бэкенда, но имеет место быть, и не говорить о нем нельзя.
1) Пагинация
Стандартная тема, скипаем n, берем m элементов из БД. На практике, если используются прослойки, например MediatR, то тут универсальности не добъешься, придется в хэндлере медиатора отдавать IQueryable, что не очень подходит как универсальное code-design решение, которое может выбиваться из устоявшегося стиля подхода существующих зрелых проектов.
2) Поток
Почему-то не очень распространенный подход, но очень классный, в своей простоте. Пока фронт отрисовывает всё поступающие элементы, бэк обрабатывает и выдает все новые, не забивая при этом память, т.к. нет потребности хранить весь ответ. Есть те-же минусы, что и у 1, но при этом очень сильный бенефит который этот минус прикрывает.
3) Сжатие
Можно включить сжатие всех ответов на уровне приложения, но это занимает некоторые ресурсы процессора, если есть возможность настроить для конкретных эндпоинтов то круто (не копал глубоко в настройки этой фичи). Но не думаю что комрпессия будет сильно выиграшнее чем просто gRPC или контракт на Protobuf, где убираются самые повторяющиеся части ответов — названия полей.
4) Заголовок Cache-Control
Думаю что для одного и того-же клиента, врятли сильно изменится информация в выдаче в течение 5 секунд или 5 минут, в зависимости от кейса. А мы сэкономим на валидациях, мапперах и обращениях в БД.
0) GraphQL
Понятно, почему я против того, чтобы фронт решал какие данные из БД ему нужны, и как страдает (исчезает) от этого слой бизнес логики бэкенда, но имеет место быть, и не говорить о нем нельзя.
1) Пагинация
Стандартная тема, скипаем n, берем m элементов из БД. На практике, если используются прослойки, например MediatR, то тут универсальности не добъешься, придется в хэндлере медиатора отдавать IQueryable, что не очень подходит как универсальное code-design решение, которое может выбиваться из устоявшегося стиля подхода существующих зрелых проектов.
[HttpGet]
public async Task<IActionResult> Get([FromQuery] int pageNumber = 1, [FromQuery] int pageSize = 100)
{
return Ok(await _dbContext.Data
.Skip((pageNumber - 1) * pageSize)
.Take(pageSize)
.ToListAsync());
}
2) Поток
Почему-то не очень распространенный подход, но очень классный, в своей простоте. Пока фронт отрисовывает всё поступающие элементы, бэк обрабатывает и выдает все новые, не забивая при этом память, т.к. нет потребности хранить весь ответ. Есть те-же минусы, что и у 1, но при этом очень сильный бенефит который этот минус прикрывает.
[HttpGet]
public async IAsyncEnumerable<DataEntity> GetDataAsStream()
{
await foreach (var item in _dbContext.Datas.AsAsyncEnumerable())
yield return item;
}
}
3) Сжатие
Можно включить сжатие всех ответов на уровне приложения, но это занимает некоторые ресурсы процессора, если есть возможность настроить для конкретных эндпоинтов то круто (не копал глубоко в настройки этой фичи). Но не думаю что комрпессия будет сильно выиграшнее чем просто gRPC или контракт на Protobuf, где убираются самые повторяющиеся части ответов — названия полей.
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCompression(options =>
{
options.EnableForHttps = true;
});
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
app.UseResponseCompression();
}
4) Заголовок Cache-Control
Думаю что для одного и того-же клиента, врятли сильно изменится информация в выдаче в течение 5 секунд или 5 минут, в зависимости от кейса. А мы сэкономим на валидациях, мапперах и обращениях в БД.
[HttpGet]
[ResponseCache(Duration = 60)] // кэш на 60 секунд
public IActionResult GetData()
{
return Ok(_dbContext.Datas.ToList());
}
🔥1
Российский поисковик - говно.
Советский менталитет все еще говорит нам хейтить самих себя просто за то что мы есть. А на самом деле то что? А вы знаете еще хоть один пример успешной национальной поисковой системы, которая вышла на уровень транснациональной? Десятки национальных поисковиков в каждой стране мира, но в топе (кроме гугла из Америки) только Россия и Китай.
Советский менталитет все еще говорит нам хейтить самих себя просто за то что мы есть. А на самом деле то что? А вы знаете еще хоть один пример успешной национальной поисковой системы, которая вышла на уровень транснациональной? Десятки национальных поисковиков в каждой стране мира, но в топе (кроме гугла из Америки) только Россия и Китай.
MinimalAPI vs Controllers
Тут мужик сравнил быстродействие эндпоинтов с использованием вышеупомянутых подходов по декларированию и обработке API. Почитал, ничего сверхъестественного не получилось в итоге. MinimalAPI примерно на 8% быстрее отрабатывает, и в 1.5 раза меньше выделяет памяти в процессе запроса.
Но у MinimalAPI есть свои минусы перед обычными контроллерами:
1) В первую очередь самый большой минус исходит из самого большого плюса: ПРОСТОТА. Простая декларация имеет сложности в поддержке, при росте и усложнении проекта, соответственно простой API лучше использовать для простых приложений.
2) Из-за своей небольшой распространенности, имеет меньше примеров и не все разработчики смогут с наскока с ним работать.
Тут мужик сравнил быстродействие эндпоинтов с использованием вышеупомянутых подходов по декларированию и обработке API. Почитал, ничего сверхъестественного не получилось в итоге. MinimalAPI примерно на 8% быстрее отрабатывает, и в 1.5 раза меньше выделяет памяти в процессе запроса.
Но у MinimalAPI есть свои минусы перед обычными контроллерами:
1) В первую очередь самый большой минус исходит из самого большого плюса: ПРОСТОТА. Простая декларация имеет сложности в поддержке, при росте и усложнении проекта, соответственно простой API лучше использовать для простых приложений.
2) Из-за своей небольшой распространенности, имеет меньше примеров и не все разработчики смогут с наскока с ним работать.
Steven-Giesel
Comparing the performance between the Minimal API and classic Controllers
Today, we are going to benchmark the performance of the Minimal API in ASP.NET 9 (and for reference against ASP.NET 8 as well) against the classic Controllers. We will test a few scenarios and check how the performance of the Minimal API compares to the classic…
Rate Limiter
А еще, вместо того, чтобы бороться с причинами долгой работы API — можно бороться с его последствиями! Для этого просто ограничим пользователей, чтобы они не могли делать много запросов и тогда мы разгрузим мощности для наших неоптимизированных операций!
Нужно всего лишь добавить NuGet:
И добавить ограничения:
Так мы запрещаем обращаться к нашему апи, если за секунду к нам пришло больше 100 запросов.
Если без шуток, то это правда имеет реальные бенефиты:
* Большое количество запросов может замедлить работу приложения или даже привести к сбоям.
* Помогает остановить атаки методом перебора, ограничивая количество попыток входа в систему или вызовов API.
* Гарантирует справедливое распределение ресурсов API между всеми клиентами.
* Для облачных сервисов с тарификацией за каждый запрос, сокращение количества запросов может помочь снизить расходы.
В этой-же библиотеке есть и более гибкие способы, с линейным распределением и пр., по ограничению запросов (название соответствует политике, подобно Fixed Window Limiting —
1) Token Bucket Limiting — разрешает пакетный трафик путем накопления токенов. Запросы потребляют токены, и когда их не остается — запросы ограничиваются.
2) Sliding Window Limiting — сглаживает распределение запросов, проверяя частоту по скользящему окну вместо фиксированного временного окна.
3) Concurrency Limiting — ограничивает количество одновременных запросов.
Ну и Best Practice:
1) Детализация ограничений: Ограничения в зависимости от клиента, пользователя или IP-адреса. Например, вам могут потребоваться более строгие ограничения для пользователей, не прошедших проверку подлинности, и более мягкие ограничения для доверенных клиентов.
2) Код ответа: При превышении лимитов скорости возвращаются значимые сообщения с кодом состояния
3) Заголовки: Используйте заголовки ограничения скорости
А еще, вместо того, чтобы бороться с причинами долгой работы API — можно бороться с его последствиями! Для этого просто ограничим пользователей, чтобы они не могли делать много запросов и тогда мы разгрузим мощности для наших неоптимизированных операций!
Нужно всего лишь добавить NuGet:
$ dotnet add package Microsoft.AspNetCore.RateLimiting
И добавить ограничения:
builder.Services.AddRateLimiter(options =>
{
options.AddFixedWindowLimiter("HundredPerSecondPolicy", opt =>
{
opt.PermitLimit = 100;
opt.Window = TimeSpan.FromSeconds(1);
opt.QueueProcessingOrder = QueueProcessingOrder.OldestFirst;
opt.QueueLimit = 2;
});
});
app.UseRateLimiter();
Так мы запрещаем обращаться к нашему апи, если за секунду к нам пришло больше 100 запросов.
Если без шуток, то это правда имеет реальные бенефиты:
* Большое количество запросов может замедлить работу приложения или даже привести к сбоям.
* Помогает остановить атаки методом перебора, ограничивая количество попыток входа в систему или вызовов API.
* Гарантирует справедливое распределение ресурсов API между всеми клиентами.
* Для облачных сервисов с тарификацией за каждый запрос, сокращение количества запросов может помочь снизить расходы.
В этой-же библиотеке есть и более гибкие способы, с линейным распределением и пр., по ограничению запросов (название соответствует политике, подобно Fixed Window Limiting —
options.AddFixedWindowLimiter):1) Token Bucket Limiting — разрешает пакетный трафик путем накопления токенов. Запросы потребляют токены, и когда их не остается — запросы ограничиваются.
2) Sliding Window Limiting — сглаживает распределение запросов, проверяя частоту по скользящему окну вместо фиксированного временного окна.
3) Concurrency Limiting — ограничивает количество одновременных запросов.
Ну и Best Practice:
1) Детализация ограничений: Ограничения в зависимости от клиента, пользователя или IP-адреса. Например, вам могут потребоваться более строгие ограничения для пользователей, не прошедших проверку подлинности, и более мягкие ограничения для доверенных клиентов.
2) Код ответа: При превышении лимитов скорости возвращаются значимые сообщения с кодом состояния
429 Too Many Requests. С добавлением информации о том, когда клиент сможет повторить попытку снова.3) Заголовки: Используйте заголовки ограничения скорости
X-RateLimit-Limit, X-RateLimit-Remaining и X-RateLimit-Reset, чтобы предоставлять клиентам обратную связь об их текущем состоянии ограничений.🔥1
image_2024-11-07_15-38-19.png
2.5 MB
DDD
Сколько разных версий схем DDD существует, это просто мое увожение... Каждый рисует кто во что горазд, и везде разные объяснения одних и тех же вещей)))
Сколько разных версий схем DDD существует, это просто мое увожение... Каждый рисует кто во что горазд, и везде разные объяснения одних и тех же вещей)))
Лайфхак от головной боли по выравниванию и обновлению версий NuGet пакетов:
1) Установить утилиту глобально:
2) Обновить всё до последней минорной версии:
3) Обновить вообще всё до самых последних версий:
Да, придется подождать, в зависимости от количества пакетов и их переплетений по зависимостям (5-30 мин), но это сильно быстрее, чем самому распутывать клубки тянущихся друг за другом зависимостей и обновлять пакеты вручную, один за другим.
1) Установить утилиту глобально:
dotnet tool install --global dotnet-outdated-tool
2) Обновить всё до последней минорной версии:
dotnet outdated --version-lock major --upgrade
3) Обновить вообще всё до самых последних версий:
dotnet outdated --upgrade
Да, придется подождать, в зависимости от количества пакетов и их переплетений по зависимостям (5-30 мин), но это сильно быстрее, чем самому распутывать клубки тянущихся друг за другом зависимостей и обновлять пакеты вручную, один за другим.