Лучший tech_stack для стартапов:

Когда начинаешь пилить какой-то продукт с нуля, как правило выбор идет в сторону технологий, в которых ты уже достаточно хорош, и чаще всего это самый правильный подход. Знаешь питон - берешь FastAPI в бек. Всю жизнь юзаешь Vue? Выбираешь Vue.

Но такие решения не всегда могут быть оптимальны. Очень часто можно упускать какие-то революционные технологии которые ускоряют разработку в разы.

Несмотря на то что я большой любитель .NET'а в бекенде, все новые свои проекты я делаю не на нём. Сейчас я полностью погрузился в изучение и использование t3-stack'а

Что есть t3-stack? Это достаточно известный опен-сорсный стек построенный на следующих технологиях:
- Next.js (имба)
- tRPC (имба)
- Tailwind
- Prisma (имба)
- NextAuth (ультраимба)

Чем стек так примечателен? Тем что я эффективнее разрабатываю Fullstack проекты даже быстрее чем на C# + MVC. Хотя казалось бы. Учитывая что у меня опыта сильно меньше на нём чем на C#, это какой-то невероятный результат. Вот за счёт чего он достигается:

✨ tRPC. Имеет встроенную интеграцию с react-query. Так как он запилен поверх Next'а, то вот как теперь выглядит процесс разработки: делаешь бекенд-ручку, у тебя СРАЗУ появляются frontend типы с api-client'ы, которые работают сразу из коробки без предварительной настройки. Буквально за 1 минуту можно сделать запросы с фронта в бек и проверить их прям во время npm dev - никаких проблем с выбором URL хоста от env переменных, никаких болей с генерацией неюзабельных api клиентов по swaggergen'у, никакой боли с тем что надо (боже упаси) писать апи клиенты самостоятельно на axios или fetch-api. Короче говоря - game changer.

✨ NextAuth. Опять же, связывать фронтенд с бекендом это всегда была дикая боль. Но не с NextAuth. Опять же, т.к оно построено на Next, NextAuth связывает методы который ты вызываешь с фронта и привязывает его к бекенду приложения. Менеджмент сессий, куки, жвт - теперь об этом вообще даже не нужно думать, все задается конфигом и делается автоматически, а вам надо лишь вызывать нужные методы по типу "login", "signin" и т.д. А нужные данные по сессиям вам предоставят ввиде react-хуков. Подключение Google аутентификации занимает, без шуток, 3 минуты, и оно будет прям сразу работать в SPA приложении. Это основная боль которую я ощущал в ASP.NET Core - настройка нормальной authn/authz.

✨ Next.js - за счет того что он сочетает в себе фронт и бек приложение одновременно, он позволяет двум технологиям выше существовать в принципе. Плюс он развивается невероятными темпами, имеет кучу фичей по типу очень удобного file-роутинга, за что огромная благодарность Vercel

✨ Tailwind - сначала я его невзлюбил. Но как подпривык к нему и к инфраструктуре вокруг него, то он заиграл новыми красками. Особенно заходит юзать его в связке с shadcn-ui, получается разрабатывать фронтовую часть ЕЩЕ быстрее.

✨ Prisma - вторая по крутости ORM из всех что я пробовал после EntityFramework, а пробовал я довольно много разных на разных языках - sqlAlchemy, EF, Dapper, Gorm, Hibernate. Имеет очень крутое и удобное API.

Что в итоге получаем? Связать фронт и бек и сделать условный круд который будет потребляться фронтендом занимает x5 меньше времени чем на других стеках на которых я делал что-то подобное - FastApi c Vue и ASP.NET с React.

Я всем очень сильно советую попробовать этот стек для своих проектов, потому что это буквально идеальный набор инструментов для быстрого прототипирования, создания MVP и тестирования гипотез. А вы что думаете? Какой стек считаете идеальным? Пишите в комментах 🍋🍋🍋

#mikrotik #cve

Remote and authenticated attackers can use the vulnerability to get a root shell on the router. (CVE-2023-30799)

https://vulncheck.com/blog/mikrotik-foisted-revisited

А вот и долгожданный анализ всего слитого с Яндекса: аналитика, метрика, реклама. Громадный поток информации со всех источников Яндекса хоть пугает, но вполне ожидаем.

https://www.confiant.com/news/the-yandex-leak-how-a-russian-search-giant-uses-consumer-data

Сжимаем картинки

Картинки - один из важнейших составляющих сайта. Логотипы, иконки, мемы, схемы - все это картинки. По данным w3techs только 3.6% сайтов не используются никакие картинки, так что вопрос оптимизации изображений существовал с рождения интернета. Уменьшение размера изображения ускоряет загрузку сайта, уменьшает фрустрацию пользователя и потенциально повышает авторитет сайта в глазах потенциального клиента. В этой статье я ставлю цель разобраться в способах оптимизации передачи картинок пользователю в вебе.

Какие есть методы запаковки изображения? Самый простой - bmp, где мы под каждый пиксель выделяем одинаковое количество бит, без сжатия, потерь, но логично, что файл из-за этого много весит. Скакнем на много поколений вперед и посмотрим формат jpeg. Jpeg использует сжатие с потерями путем определения похожих цветовых областей внутри изображения и преобразования их в фактически один и тот же цветовой код. За счет этого размер файла уменьшается, без уменьшения размера картинки. Напоследок рассмотрим формат png, самый распространённый формат в вебе. PNG хранит информацию в сжатом виде, но без потерь, в отличие от jpeg. Файл png состоит из сигнатуры и последовательности чанков. По этой причине при загрузке сайта большие файлы PNG отображаются постепенно, по мере прихода этих чанков. Для веба можно использовать прочие способы оптимизации PNG - обрезания alfa канала, оптимизации палитры или банальный даунскейл(что на самом деле хорошее решение, ибо с каждым годом мегапиксели на телефонах растут и растут). Для подробного ресерча можете почитать про TruePNG, CryoPNG, PngWolf и прочее. Однако форматы JPEG, PNG были разработаны аж в 20 веке, должны же были придумать новые способы, заточенные на веб, для передачи картинок. Самый распространенный из них - webp(9%) и AVIF(0.1%).

WebP. В 2010 году Google выпустили формат WebP как альтернативу PNG и JPEG. Он использует алгоритм сжатия ключевых кадров из видеокодека VP8, поэтому искажение исходного изображения выглядит иначе относительно других форматов. Webp обещает сжатие без потерь на 26% лучше, чем у PNG. Так же webp поддерживает прозрачность и анимацию, что позволяет так же обойтись без GIF(или APNG) Для работы напрямую с энкодером webm можно изучить гугловый cwebp.

AVIF. AVIF один из последних форматов, основанный на современной AV1. Он гарантирует значительное уменьшение размера файла при сохранении визуального качества изображения. Так же формат AVIF может использовать многопоточность для более быстрого кодирования и декодирования изображений на современных многоядерных процессорах. Но avif - ОЧЕНЬ долгий для декодинга формат. Может легко получиться, что страница будет тормозить с ним больше, чем WEBP с учетом скачивания дополнительных байтов.

JPEG XL. Jpeg XL основан на инновационных разработках Google PIK и Cloudinary FUIF, являясь наследников FUIF, но превосходит их. Однако сейчас никакой(кроме safari) браузер не поддерживает jpeg xl, но это вопрос времени, ибо для большинства браузеров уже есть флаги для активации этого формата. JXL - много обещающей формат, способный окончательно вытеснить PNG

Через несколько лет можно будет сказать, что формат PNG окончательно устарел, поскольку разница с WebP и JPEG XL очень существенная.

Комбинируя все подходы. Когда-то, еще очень давно(на кубке, если я не ошибаюсь) сотрудник МТС рассказывал мне об их передовом сервисе для оптимизации картинок. Дело в том, что они пережимают все картинки на лету в webp и avif под размеры верстки пользователя. Конечно с кешированием и т д. Похожие решения есть для nginx, imgproxy как отдельный сервис и т. д. Суть в том, что оптимизация картинок - нетривиальная вещь и может быть осуществлена без необходимости усложнения кодовой базы. Оптимизируйте, ускоряйте, кайфуйте.
@sanspie_notes

Слышали про Python в Excel?

Microsoft выпустили официальный отчёт о безопасности данных в этой связке - https://support.microsoft.com/en-us/office/data-security-and-python-in-excel-33cc88a4-4a87-485e-9ff9-f35958278327

> Use this command to disable all security warnings. This is the default setting for Python in Excel.

Новая волна макросов в Экселе через 3..2..1

Пум-пум-пум. Там Opena AI выкатили значительную фичу - тепeрь можно файнтюнить GPT 3.5 Turbo.

По сути это LoRa-as-a-service. Готовите json файл со своими диалогами, загружаете на сервер OpenAI (если хотите без этого - то вам к LLaMa и сородичам, кек) через API и через апишку же и запускаете трейнинг.

Цена вопроса:
- Во время тренировки: $0.008 / 1K токенов
- Стоимость ввода во время инференса вашей кастомной модели: $0.012 / 1K токенов
- Стоимость генерации: $0.016 / 1K Tokens.

В общем, для babbage-002 кастомная модель обойдется в 4 раза дороже,
а для davinci-002 в 6 раз дороже чем базовая. Оно, конечно, понятно - нужно же отдельную ноду поднять и зарезервировать GPU под вашу индивидуальную модель.

Гайд по файн-тюнингу GPT 3.5

@ai_newz

Довольно интересна и свежая серия статей, в частности по AD и чуть-чуть туннелям

1. https://blog.bitsadmin.com/living-off-the-foreign-land-windows-as-offensive-platform

2. https://blog.bitsadmin.com/living-off-the-foreign-land-windows-as-offensive-platform-part-2

3. https://blog.bitsadmin.com/living-off-the-foreign-land-windows-as-offensive-platform-part-3

#ad #pentest #redteam #lofl

Создание telegram-ботов с интерактивным меню

Я знаю, что среди мои читателей есть те, кто сталкивается с разработкой телеграм ботов.

Я выложил на Habr статью, где рассматриваю несколько проблем организации UI с помощью inline-меню и способы их решения.

> https://habr.com/ru/articles/757236/

Так же там упоминается мой проект aiogram-dialog, реализующий указанные в статье подходы, у которого на днях вышла версия 2.0.

Дополнительные материалы:
* https://dev.to/marwan8/getting-started-with-the-viper-architecture-pattern-for-ios-application-development-2oee
* https://freecontent.manning.com/http-session-management/
* https://en.wikipedia.org/wiki/Graphical_widget
* https://developer.android.com/guide/components/activities/tasks-and-back-stack
* https://aiogram-dialog.readthedocs.io/

Интересная идея - использовать llm для визуализации бесед в разных группах и каналов

https://www.youtube.com/watch?v=qoeOdrQ5bZ0

Довольно редкое явление, когда RCE уязвимость присутствует и в веб-браузерах на основе Chrome/Chromium (включая Edge), и в веб-браузерах на основе Firefox. Уязвимость CVE-2023-4863 нашли в libwebp, библиотеке для работы с растровыми изображениями в формате WebP (замена PNG и JPEG). Поэтому любой софт, который умеет открывать изображения в WebP, вполне вероятно использует libwebp и поэтому будет уязвим. Google пишут, что эксплоит есть в паблике.

И это не только про веб-браузеры. Пишут, что libwebp также используется в Electron framework, Signal, Honeyview, Affinity, Gimp, Inkscape, LibreOffice, Telegram, Thunderbird (есть патч), ffmpeg и других.

А как насчёт Safari? Про него пока молчат, но некоторые СМИ делают предположения, что недавние эксплуатируемые RCE в продуктах Apple, CVE-2023-41061 и CVE-2023-41064, "обработка вредоносного изображения может привести к выполнению произвольного кода" #BLASTPASS это про то же.

И что, как с log4j будет? Вряд ли, но видимо зацепит много кого.

@avleonovrus #libwebp

Партнёрство Cloudflare и Hugging Face

Cloudflare объявило о начале партнёрства с Hugging Face с целью сделать модели ИИ более доступными для разработчиков.


Что обещают? 👀

-В Hugging Face появятся безсерверные модели GPU без инфраструктурных "костылей" и оплат за неиспользуемые мощности. Просто выберите свою модель и работайте.

-Модели Hugging Face появятся в каталоге моделей Cloudflare

-Интеграционные инструменты Cloudflare станут частью Hugging Face Inference


Разработчики, использующие платформу Cloudflare, вскоре смогут развертывать модели Hugging Face прямо с панели управления Cloudflare, а те, кто использует Hugging Face, смогут развертывать модели непосредственно в Workers AI.

🤗 Блог

https://github.blog/2023-10-09-coordinated-disclosure-1-click-rce-on-gnome-cve-2023-43641/

CVE-2023-43641
PoC

RCE по клику в библиотеке libcue, которую использует один из компонентов Gnome. Переполнение, как и в Looney Tunables