Pandas 2.0 is out
https://pandas.pydata.org/docs/dev/whatsnew/v2.0.0.html
https://pandas.pydata.org/docs/dev/whatsnew/v2.0.0.html
👎1🤬1
Тут Hugging Face совместно с ServiceNow выложили свой copilot - StarCoder, модель, которая пишет код по вводимым параметрам(15 миллиардов токенов). Только в отличии от копайлота StarCoder опенсорсный, модель можно развернуть у себя и использовать как апи. Под капотом GPT2.
Генерирует код на уровне копайлота, выше скрин с простенькой вьюшкой в дрф, думаю с большим контекстом выхлоп был бы лучше.
Поиграться с моделью можно тут - bigcode-bigcode-playground.hf.space
или в виде чата тут - hf.co/chat
Генерирует код на уровне копайлота, выше скрин с простенькой вьюшкой в дрф, думаю с большим контекстом выхлоп был бы лучше.
Поиграться с моделью можно тут - bigcode-bigcode-playground.hf.space
или в виде чата тут - hf.co/chat
👍8🤬2👎1
This media is not supported in your browser
VIEW IN TELEGRAM
czkawka
Долгое время искал утилиту, чтобы находить похожие/совпадающие картинки, музыку, видео и т д. Сегодня наткнулся на czkawka, gui и cli программу, которая за секунды считает хеши и даже находит похожие файлы. Так же она хеширует результаты и имеет встроенный просмоторщик файлов в gui.
aur
Долгое время искал утилиту, чтобы находить похожие/совпадающие картинки, музыку, видео и т д. Сегодня наткнулся на czkawka, gui и cli программу, которая за секунды считает хеши и даже находит похожие файлы. Так же она хеширует результаты и имеет встроенный просмоторщик файлов в gui.
aur
👍9🤬2🌭2👎1
Overpass
Пару недель назад я решал одну задачу для хакатона ЛЦТ, в которой нам нужно было собрать данные по различным точкам(достопримечательности, отели, ресторанны, кафе и т д) для того, чтобы простаивать маршруты по ним. Одним из источников информации, который мы взяли для системы был open street maps. Однако возник вопрос, как можно выгрузить десятки тысяч точек из такой сложной штуки как open sreet maps (далее osm).
Для тех, кто не знает, что же такое open street maps, попытаюсь кратко рассказать. Osm - аналог Google Maps, бесплатно предоставляющий всему миру данные карт, собранные при помощи маперов - людей, которые заносят данные об окружающей местности в osm. Чем же он лучше, чем Google, Bing, Yandex maps или другой популярный поставщик карт? Ну, во-первых, osm - некоммерческий продукт, что лишает компаний возможности монетизировать локацию, предпочтения, поисковые запросы пользователей. Во-вторых, данные в osm обновляют юзеры, что делают информацию в osm наиболее актуальной. Так же не стоит забывать, что osm можно скачать, запустить у себя на сервере, нарисовать что-то поверх и сделать частью своего сервиса, что уменьшает опасность атак на цепочку поставок, а так же делает компании более независимыми.
Отлично! Но как можно получить данные, не в интерфейсе osm, а, например, в виде геожсонов? Тут нам на помощь приходит Overpass API. Overpass API — это серверное ПО с открытым исходным кодом, созданное для обработки пространственных запросов к данным osm. По умолчанию overpass работает c xml, однако так же можно воспользоваться их QL, который позволяет фильтровать точки в более-менее человекочитаемом формате. Например, вот запрос, чтобы получить все магазины “Дикси” в России:
Теперь дело за малым: написать запрос и посмотреть что он отдает. Для этого подходит мощный fronted клиент для overpass - overpass turbo. Он не только позволяет отобразить результаты запроса на карте, но и имеет помощника, который как-то криво, но составит запрос.
Таким образом, мы можем автоматизировать всякую работу с данными на карте, подготовить данные для своей системы или просто проанализировать агрегированную информацию.
Пару недель назад я решал одну задачу для хакатона ЛЦТ, в которой нам нужно было собрать данные по различным точкам(достопримечательности, отели, ресторанны, кафе и т д) для того, чтобы простаивать маршруты по ним. Одним из источников информации, который мы взяли для системы был open street maps. Однако возник вопрос, как можно выгрузить десятки тысяч точек из такой сложной штуки как open sreet maps (далее osm).
Для тех, кто не знает, что же такое open street maps, попытаюсь кратко рассказать. Osm - аналог Google Maps, бесплатно предоставляющий всему миру данные карт, собранные при помощи маперов - людей, которые заносят данные об окружающей местности в osm. Чем же он лучше, чем Google, Bing, Yandex maps или другой популярный поставщик карт? Ну, во-первых, osm - некоммерческий продукт, что лишает компаний возможности монетизировать локацию, предпочтения, поисковые запросы пользователей. Во-вторых, данные в osm обновляют юзеры, что делают информацию в osm наиболее актуальной. Так же не стоит забывать, что osm можно скачать, запустить у себя на сервере, нарисовать что-то поверх и сделать частью своего сервиса, что уменьшает опасность атак на цепочку поставок, а так же делает компании более независимыми.
Отлично! Но как можно получить данные, не в интерфейсе osm, а, например, в виде геожсонов? Тут нам на помощь приходит Overpass API. Overpass API — это серверное ПО с открытым исходным кодом, созданное для обработки пространственных запросов к данным osm. По умолчанию overpass работает c xml, однако так же можно воспользоваться их QL, который позволяет фильтровать точки в более-менее человекочитаемом формате. Например, вот запрос, чтобы получить все магазины “Дикси” в России:
[out:json]; # указываем оператором настроек, что хотим ответ в виде jsonТаким нехитрым образом мы получаем json с точками, всякой информацией типа адреса и т д по тем “тегам”, что мы хотим. Язык описания запросов очень мощный и позволяет даже использовать регулярные выражения, составлять пересечения зон и областей (некоторые интересные запросы можно посмотреть на картинке). Полный набор операторов можно найти тут - https://dev.overpass-api.de/overpass-doc/en/.
(area["ISO3166-1"="RU"];)->.ru; # создаем фильтр ru, с точками только из рф
(node[shop][name="Дикси"](area.ru);); # оператором node создаем набор данным
со всеми магазинами с називанием Дикси
и применяем фильтр с предыдущей строки
out;
Теперь дело за малым: написать запрос и посмотреть что он отдает. Для этого подходит мощный fronted клиент для overpass - overpass turbo. Он не только позволяет отобразить результаты запроса на карте, но и имеет помощника, который как-то криво, но составит запрос.
Таким образом, мы можем автоматизировать всякую работу с данными на карте, подготовить данные для своей системы или просто проанализировать агрегированную информацию.
👍8👎1🔥1
Релиз FastAPI 0.100.0
Из ключевого - stable поддержка Pydantic 2
В FastAPI сериализация, десериализация и валидация входных данных осуществляется библиотекой Pydantic. Во 2 версии pydantic была переписана на Rust, который ускорил работу библиотеки(в некоторых местах) аж в 20 раз.
Из ключевого - stable поддержка Pydantic 2
В FastAPI сериализация, десериализация и валидация входных данных осуществляется библиотекой Pydantic. Во 2 версии pydantic была переписана на Rust, который ускорил работу библиотеки(в некоторых местах) аж в 20 раз.
Tiangolo
Release Notes - FastAPI
FastAPI framework, high performance, easy to learn, fast to code, ready for production
👍4
Forwarded from ЛаймStyle 🍋 (MadL1me)
Лучший 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 и тестирования гипотез. А вы что думаете? Какой стек считаете идеальным? Пишите в комментах 🍋🍋🍋
Когда начинаешь пилить какой-то продукт с нуля, как правило выбор идет в сторону технологий, в которых ты уже достаточно хорош, и чаще всего это самый правильный подход. Знаешь питон - берешь 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 и тестирования гипотез. А вы что думаете? Какой стек считаете идеальным? Пишите в комментах 🍋🍋🍋
Create T3 App
The best way to start a full-stack, typesafe Next.js app.
👍7
Forwarded from Волосатый бублик
#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
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
👍1
Forwarded from эйай ньюз
Аннотированный код
Наткнулся на классный сайт, где собран код некоторых популярных моделей (или их частей), например Stable Diffusion, GPT, Switch Tranformer, MPL-Mixer и др. Весь цимес в том, что каждая строка кода задокументирована, и показаны соответствующие математические формулы.
Будет полезно тем, кто любит начининать изучать модели сразу с кода. Как раз занятие на воскресенье.
На скринах - код DDIM и Adam.
https://nn.labml.ai/
@ai_newz
Наткнулся на классный сайт, где собран код некоторых популярных моделей (или их частей), например Stable Diffusion, GPT, Switch Tranformer, MPL-Mixer и др. Весь цимес в том, что каждая строка кода задокументирована, и показаны соответствующие математические формулы.
Будет полезно тем, кто любит начининать изучать модели сразу с кода. Как раз занятие на воскресенье.
На скринах - код DDIM и Adam.
https://nn.labml.ai/
@ai_newz
🔥7
А вот и долгожданный анализ всего слитого с Яндекса: аналитика, метрика, реклама. Громадный поток информации со всех источников Яндекса хоть пугает, но вполне ожидаем.
https://www.confiant.com/news/the-yandex-leak-how-a-russian-search-giant-uses-consumer-data
https://www.confiant.com/news/the-yandex-leak-how-a-russian-search-giant-uses-consumer-data
👍7🌚4
Сжимаем картинки
Картинки - один из важнейших составляющих сайта. Логотипы, иконки, мемы, схемы - все это картинки. По данным 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
Картинки - один из важнейших составляющих сайта. Логотипы, иконки, мемы, схемы - все это картинки. По данным 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
👍6❤2