Эта небольшая история — живое свидетельство того, как самые простые решения (иногда) могут оказаться очень эффективными. В одном из проектов руководство взяло курс на оптимизацию бюджета на инфраструктуру. В результате анализа всех статей расходов стало очевидным, что заметно выдаются счета за сетевой трафик из Amazon S3-бакета, где хранится публичная статика веб-приложения. Так появилась задача найти и реализовать максимально недорогой и решающий бизнес-задачу способ.

Мы живем в удивительное время — каждый становится экспертом, прочитав пару статей из интернета. Есть, конечно, сферы жизни, в которых мы были экспертами всегда, еще задолго до появления всемирной сети. Например, футбол, хоккей, отношения и управление страной.

Но теперь мы дополнительно освоили и специальности, требующие специфических знаний. Например, медицина. Google в помощь — и вот мы поправляем врачей, сами ставим себе диагноз и назначаем лечение. И только когда совсем уже худо, когда петух непрерывно начинает клевать в то место, где спина теряет свое благородное название, мы бежим к врачу, которому приходится не только лечить запущенную болезнь, но и бороться с последствиями нашего интернет-лечения.

Подобная ситуация и с налогами. Интернет пестрит всевозможными советами, как и что делать во время налоговой проверки, очень часто прямо противоречащими друг другу.

Кто-то советует сразу включить видеокамеру и диктофон, кто-то предлагает выделить кабинет с чайником, СВЧ-печью и заполненным холодильником. Одни предлагают свести устное общение к минимуму, другие дают советы, как расположить к себе, в стиле «называйте чаще по имени», «делайте комплименты, но не льстите», «попросите совета на будущее». Одни советы слишком общие, другие излишне конкретизированные, а некоторые вообще опасны и могут привести к негативным и непредсказуемым последствиям.

Испытывая желание нести знания в массы и искренне переживая за налоговое здоровье наших сограждан, мы тщательно проанализировали имеющуюся информацию о проведении налоговых проверок, а также обобщили наш 10-летний опыт сопровождения налоговых проверок.

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

Обратите внимание — именно минимизация, так как доначисления, конечно, будут. «Нулевые» проверки — это нонсенс. Ведь от эффективности проверок зависят показатели инспекции и, соответственно, премирование сотрудников. Поэтому доначисления будут, но то, в каком объеме и, самое главное, будут ли у вас основания их оспорить в суде, во многом зависит от качества ваших действий во время налоговой проверки.

KubeHelper - это продукт, который упрощает решение многих ежедневных задач связанных с управлением Kubernetes через веб интерфейс. Поиск, анализ, запуск команд, “cron jobs”, репорты, фильтры, git синхронизация и многое другое. 

KubeHelper это не ещё одна попытка отобразить Kubernetes API в графическом интерфейсе. Не попытка заменить Lens, официальный Dashboard или другие продукты. Это мой скромный вклад в Kubernetes Open Source сообщество. Проект не имеет какого-то узко специализированного направления и содержит довольно много различных функций которые будут полезны в ежедневной работе с Kubernetes.

Теперь посты на Habr будут читаться за вас!

В данной статье я хочу показать, как можно совместить утренние сборы на работу с прочтением статей на Habr. Для этого мы напишем простое расширение для браузеров на базе chromium (в частности, Chrome и Opera), которое будет зачитывать для нас вслух открытый во вкладке пост на Habr.

Расширение может быть использовано для чтения статей как на русском языке, так и на английском.

При поиске проблем в RDBMs разработчик обычно подозревает медленные запросы. А что, если дело не в них? О том, какого типа запросы дают нагрузку на базу данных, не позволяя вашему приложению работать должным образом, рассказал в своем докладе на конференции Saint HighLoad++ Online 2020 администратор баз данных Data Egret Андрей Сальников. 

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

Предположим, мы создали кластер Kubernetes. И кто-то из команды разработчиков хочет развернуть и протестировать на нем новое приложение. Как нам предоставить ему доступ в кластер?

Команда Kubernetes aaS Mail.ru Cloud Solutions перевела простое руководство по предоставлению доступа к новому кластеру Kubernetes, включая настройку аутентификации и привязку ролей. Автор показывает процесс, используя клиентский сертификат x509.

Только самый-самый ленивый человек не написал о том, как искать работу на удаленке. Большинство советов про то, как откликнуться, пройти собеседование и так далее. Меня интересует другое — где вообще удобно искать вакансии. Составил свой рейтинг, протестировав 10 самых известных агрегаторов.

Что будет, если разрешить лишнее при создании подов в Kubernetes? Зависит от того, какие неймспейсы хоста и контексты безопасности разрешены. Здесь мы поговорим о восьми небезопасных конфигурациях подов и методах эскалации привилегий. Эта статья и созданный для нее репозиторий помогут пентестерам и администраторам разобраться в распространенных ошибках конфигурации.

Администраторы смогут увереннее применять ограничения по умолчанию для создания подов. Возможно, поды с доступом к ресурсам хоста нужно ограничить неймспейсом, который доступен только администраторам, — по принципу наименьших привилегий.

Пентестеры получат представление о том, как показать последствия слишком либеральной политики безопасности подов. В репозитории вы найдете для этого готовые манифесты и инструкции.

Существуют разные способы создания монорепозитория в node.js, есть разные библиотеки для этих целей: yarn workspaces, lerna и так далее. Но сегодня я хочу коротко рассказать о монорепозитории на typescript, используя только npm.

Для многих систем характерен паттерн постоянного накопления данных с течением времени. Причем основная их масса больше никогда не изменяется - то есть они пишутся в режиме append-only.

Это не только различного рода логи и метрики оборудования, но и такие, казалось бы, несвязанные вещи, как переписка между пользователями или комментарии к новостям.

Около года назад я уже писал про модель организации секционирования таких данных и вызываемые этим каскадные изменения в структуре БД. А сегодня на примере нашего сервиса анализа логов PostgreSQL-серверов разберем особенности обслуживания организованных так баз, и как грамотный подход (и немного ночной работы) может сократить затраты на инфраструктуру в разы.

Я занимаюсь развитием агентства контент-маркетинга на зарубежных ресурсах уже пять лет из них более двух лет развиваю еще и собственный SaaS-стартап для международного рынка. Таким образом я сам постоянно тестирую существующие методы продвижения на своем же продукте. 

Ко мне очень часто обращаются предприниматели, которые уже пробовали продвигать свои проекты на зарубежных рынках и обожглись. «Facebook - это слив денег», «сделали статью, продаж не было вообще», «работаем над SEO, но особо не растем» – неудивительно, что после такого все маркетологи кажутся шарлатанами, а инструменты – неработающей ерундой.

Сегодня я расскажу о том, какие ошибки можно совершить при продвижении стартапа на зарубежных рынках, какие ожидания стоит сформировать, и что может сработать на самом деле.

В данной статье мы поговорим о том, как реализовать оркестратор бесконечных задач с использованием очередей. Как конечная цель: нам необходимо реализовать систему, способную управлять задачами с длительным сроком жизни, систему распределённую, где группа задач хостятся на определенном сервере и в случае отказа этого сервера, задачи автоматически перераспределяются на свободные. 

В большинстве случаев вся enterprise разработка сводится к выполнению одних и тех же требований: создается заявка, в зависимости от типа заявки у нее есть какой-то жизненный цикл, по завершению жизни заявки мы получаем (…или не получаем) желаемое. Под заявкой мы можем подразумевать все что угодно, начиная с покупки в интернет-магазине товара, денежного перевода или расчета траектории баллистической ракеты. У каждой заявки есть свой жизненный путь и что важно отметить - время жизни, и чем меньше это время, тем лучше. Иными словами, чем быстрее мой банковский перевод осуществится, тем лучше. Требования тоже схожи, побольше RPC operations per second, поменьше Latency, система должна быть отказоустойчивой, масштабируемой и должна быть готова вчера. Есть миллион инструментов, сотни баз данных, различные подходы и паттерны. И все уже давно написано, нам остается лишь правильно использовать готовые технологии в наших проектах. 

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

Когда проект зародился, то нравился каждому. Белый лист бумаги и каждый смотрел на него с ожиданием и воображал какие перспективы откроются, какие проблемы решатся.

Вот на бумагу архитектор нанес первый блок. Сзади раздалась ругань. Это разработчики, спорили...

Вам больше не помогут no-cache или max-age заголовки, вы просто не знали и не могли узнать о механизме обновления SW. Потому что про него вам не говорили.