User
Имею парочку VDSок для различных нужд (почта, веб-сервер, хранилка и т.п.) так вот, возникла необходимость скрывать порты (22, 443 и т.п.) от посторонних глаз. Немного подумав, а идея уже не новая, решил написать простенький, так сказать, ICMP knocker, то есть открытие портов по пингу. Но пингу не простому, а с определенным размером пакета. Пример для линукс:
ping -s 999 -c1 mysrv.com
Где -s - размер отправляемого сообщения, -с количество.
В нашей прошлой статье про синтез речи мы дали много обещаний: убрать детские болячки, радикально ускорить синтез еще в 10 раз, добавить новые "фишечки", радикально улучшить качество.
Сейчас, вложив огромное количество работы, мы наконец готовы поделиться с сообществом своими успехами:
Это по-настоящему уникальное и прорывное достижение и мы не собираемся останавливаться. В ближайшее время мы добавим большое количество моделей на разных языках и напишем целый ряд публикаций на эту и смежные темы, а также продолжим делать наши модели лучше (например, еще в 2-5 раз быстрее).
Попробовать модель как обычно можно в нашем репозитории и в колабе.
Существует великое множество статей об оптимизации PostgreSQL — эта «кроличья нора» весьма глубока. Когда несколько лет назад я начал разрабатывать бэкэнд аналитического сервиса, у меня уже был опыт работы с другими СУБД, такими как MySQL и SQL Server. Тем не менее, раньше мне не приходилось так фокусироваться на производительности. В прошлых проектах, над которыми я работал, либо не было жестких требований к времени обработки (DS/ML), либо не требовалось обрабатывать много строк одновременно (обыкновенные веб-приложения). Однако в этот раз мои запросы:
• состояли из 3-10 JOIN-ов по коррелирующим запросам;
• уielded от 10 до 1,000,000 строк;
• должны были выполняться в течение времени, определенного UX-ом;
• не могли быть hinted — пока Cloud SQL, управляемый PostgreSQL в Google Cloud, не стал поддерживать pg_hint_plan в конце 2021 года;
• запрещали прямой доступ к серверному процессу, чтобы, например, хакнуть некоторые perf — потому что PostgreSQL был managed.
Получение целого миллиона строк в одном API endpoint сигнализирует о проблеме в алгоритме или архитектуре. Конечно, все можно переписать и перепроектировать, но за это нужно платить.
У нас не нашлось «заклинания», которое решило бы все проблемы с производительностью SQL. Тем не менее, я упомяну здесь несколько дельных предложений, которые помогли нам и, надеюсь, смогут помочь читателю. Разумеется, это не какие-то сакральные знания. Но когда мы начинали оптимизацию, я был бы рад их прочитать или услышать.
Меня зовут Александр, я руковожу backend-разработкой в КТS. Сегодня расскажу, как написать асинхронный краулер.
Такая задача часто встречается на практике, когда нужно реализовать периодическую синхронизацию/обкачку между сервисами.
Статья написана по мотивам вебинара, который мы провели в рамках нового курса «Асинхронное программирование на Python для начинающих». Курс стартует 18 октября, поэтому, если вам интересно — загляните посмотреть.
Что будет в статье:
1. Цель
2. Исходный код
3. Планировщик
4. Задача для краулера
5. Пробный запуск
6. Промежуточный итог
7. Функции put и join
8. Semaphore
9. Остановка фонового планировщика
10. Работа краулера на примере обкачки нашего блога на Хабре
11. Заключение
Всем привет!
Для написания кандидатской диссертации я недавно составил обзор различных методов автоматического реферирования, суммаризации. Обзор получился субъективно хорошим, поэтому я публикую его и здесь. Он очень объёмный, и я разбил его на несколько частей, которые и буду постепенно выкладывать. По мере публикации ниже будут появляться ссылки на остальные части цикла.
Статьи цикла:
1) Постановка задачи автоматического реферирования и методы без учителя ⬅️
2) Извлекающие методы автоматического реферирования
3) Секреты генерирующего реферирования текстов
Это первая статья цикла, посвящённая самой задаче и методам без учителя, которым не нужен эталонный корпус рефератов: методу Луна, TextRank, LexRank, LSA и MMR.
Скрипты на Bash. Как много в этом слове. Любому разработчику рано или поздно приходится их писать. Почти никто не скажет "да, я люблю писать bash-скрипты", и поэтому этой теме уделяют мало внимания.
Я не буду пытаться сделать из вас эксперта в Bash, а просто покажу минимальный шаблон, который поможет сделать ваши скрипты более надежными и безопасными.
На IVI пользователи выбирают кино для просмотра, ориентируясь в первую очередь на постер и название фильма. Обычно правообладатель предоставляет один постер для каждого фильма и сериала, но бывают ситуации, когда могут понадобиться дополнительные/альтернативные изображения. Их создание — трудоемкая задача, потому что с помощью этих изображений нужно передать содержимое контента. Чтобы упростить её, мы прибегаем к генерации синтетических постеров. В этой статье я немного приоткрою занавес и расскажу о том, как мы удаляем визуальный мусор в процессе создания постеров.
Прим. Wunder Fund: в этой длииинной статье вы найдете ряд полезных советов по работе с Docker, как общего характера, так и Python-специфичных. Хоть мы и давно используем Docker в работе, про некоторые советы мы подумали "а что, так можно было?". Советуем вначале пролистать статью, и отметить штуки, которые покажутся актуальными для вашей текущей ситуации.
Контейнеры Docker уже довольно давно стали неотъемлемой частью инструментария разработчика, позволяя собирать, распространять и развертывать приложения стандартизированным способом.
Неудивительно, что при такой популярности наблюдается всплеск проблем безопасности, связанных с контейнеризацией. Также контейнеры представляют собой стандартизированную поверхность атаки: злоумышленники могут легко эксплуатировать ошибки в конфигурации и проникать из контейнера в хост-машину.
Меня зовут Даниил Охлопков, и я расскажу про свой подход к написанию скриптов, извлекающих данные из интернета: с чего начать, куда смотреть и что использовать.
Написав тонну парсеров, я придумал алгоритм действий, который не только минимизирует затраченное время на разработку, но и увеличивает их живучесть, робастность и масштабируемость.
Когда мы пишем статьи о своем сервере в комментариях очень часто находится читатель, который говорит:
"И зачем такой огород городить? Все это одной FFmpeg командой делается!"
Вы когда-нибудь задумывались над тем, что будете делать, окажись внезапно в чрезвычайной ситуации без сотовой или спутниковой связи, без интернета, без возможности вызвать помощь? Ваш телефон, при этом, ещё пару-тройку дней без электричества будет работать и, вероятно, сможет спасти вашу жизнь и жизни окружающих вас людей.
Meshtastic — это проект, который позволяет построить свою частную радиосеть с очень большим временем автономной работы, используя недорогие радио модули LoRa и экономичные микроконтроллеры серии ESP32.
Радиомодем связаны с вашим смартфоном по сети Bluetooth. Для некоторых сценариев использования смартфон вообще не требуется.
Обычно, время работы модема может составлять около недели. При использовании солнечных батарей время работы ретрансляционного узла не лимитировано.
Каждый участник вашей сети всегда может видеть местоположение и расстояние до всех остальных участников, а также, обмениваться любыми текстовыми сообщениями, отправленными в ваш групповой чат.
Проект подходит для создания экстренной сети связи в условиях ЧС, может использоваться в бытовом применении для оперативной связи и практически любого хобби, где отсутствует сотовая связь и Интернет.
В прошлой статье я писал про свои ML-модели для оценки отдельных компаний, но вопрос формирования итогового портфеля совсем не затрагивал. В этом посте хочу рассказать о том, как я собираю свой личный портфель, а так же поделиться сайтом, на котором реализую весь описанный в статье функционал http://stocks.ml. Дисклеймер: у автора нет экономического образования и все выводы и суждения в статье делаются на основе житейского опыта и здравого смысла.
Эта статья содержит рекомендации по написанию Dockerfile и принципам безопасности контейнеров и некоторые другие связанные темы, например про оптимизацию образов.
Если вы знакомы с контейнеризованными приложениями и микросервисами, то скорее всего понимаете, что хотя ваши сервисы "микро", но поиск уязвимостей и устранение проблем с безопасностью способен затруднить управление вашими сервисами, уже с приставкой "макро".
К счастью, большинство потенциальных проблем мы можем решить еще на этапе разработки.
Хорошо подготовленный Dockerfile исключает необходимость использовать привилегированные контейнеры, открывать порты, в которых нет необходимости, включать лишние пакеты и избегать утечки чувствительных данных. Старайтесь решить эти проблемы сразу, это поможет в дальнейшем сократить усилия на поддержку ваших приложений.
Я думаю, что все уже знают мое мнение о MERGE и почему я держусь от него подальше. Но вот еще один антипаттерн, который я постоянно встречаю, когда требуется выполнить UPSERT (UPdate inSERT — обновить строку, если она существует, и вставить, если ее нет):
Используйте глобально уникальные идентификаторы. Клиент всегда должен знать полное состояние системы. Избегайте двойных отрицаний…
