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

Еще лет 10 лет назад роль архитектора решений (Solution Architect) на проектах выполняли сами разработчики. Теперь это отдельная профессия, довольно востребованная и активно обсуждаемая. Вместе с коллегами-архитекторами подробно разбираемся во всех деталях и рассказываем, как стать архитектором в EPAM.

Привет, Хабр!

Я работаю в команде Tinkoff, которая занимается разработкой собственного центра нотификаций. По большей части я разрабатываю на Java с использованием Spring boot и решаю разные технические проблемы, возникающие в проекте.

Большинство наших микросервисов асинхронно взаимодействуют друг с другом через брокер сообщений. Ранее в качестве брокера мы использовали IBM MQ, который перестал справляться с нагрузкой, но при этом обладал высокими гарантиями доставки.

В качестве замены нам предложили Apache Kafka, которая обладает высоким потенциалом масштабирования, но, к сожалению, требует практически индивидуального подхода к конфигурированию для разных сценариев. Кроме того, механизм at least once delivery, работающий в Kafka по умолчанию, не позволял поддерживать необходимый уровень консистентности из коробки. Далее я поделюсь нашим опытом конфигурации Kafka, в частности расскажу, как настроить и жить с exactly once delivery.

Привет, хабровчане. Сегодня стартуют занятия в первой группе курса «PostgreSQL». В связи с этим, хотим рассказать вам о том, как проходил открытый вебинар по данному курсу.

---

В очередном открытом уроке поговорили о том, с какими вызовами столкнулись SQL-базы в эру облаков и Kubernetes. А заодно рассмотрели, как базы данных SQL приспосабливаются и мутируют под воздействием этих вызовов.

Вебинар провёл Валерий Безруков, Google Cloud Practice Delivery Manager в EPAM Systems.

Тут вот праздники скоро. Спросил недавно друг «как мне это все пережить?». Я сначала объяснял, а потом решил написать статью на Хабр. Рассказанное — услышит один человек, а написанное — прочитают сотни!

Меня, если честно, достаточно сильно раздражают всевозможные застолья. Потому что гораздо приятнее посидеть с паяльником или читая книгу, а не "… хорохорясь, ерепенясь и валяясь, как колода..." провести выходные. Но традиции-с, будь они неладны, формировались столетиями и не умея пить — бывает достаточно сложно вписаться в коллектив, найти нужный подход и т.д. Особенно грешат этим делом всевозможные руководящие кадры из старого поколения. Что же делать тем, для кого алкоголь и необходимость его употреблять — это просто лишняя головная боль? Самый простой ответ — НЕ ПИТЬ, но на практике полностью это очень сложно реализовать. Эффективнее в наших реалиях принять тезис «алкоголь — просто инструмент» и учиться с ним правильно работать и использовать для решения своих задач с минимизацией ущерба для здоровья.

Статью кладем в закладки и рассылаем всем друзьям, подчиненным и т.д. и т.п. Есть время подготовиться и встретить новогодние корпоративы во всеоружии. Практически уверен, что многое из описанного активно используют те, кто «не напиваться» обязан по долгу службы. Простой же обыватель чаще про это не думает, полагаясь на удачу и легкую руку. И чаще всего оказывается в проигрыше. Предупрежден = вооружен, поэтому под катом читаем, как победить в битве с алкоголем.

На Хабре много статей о том, как самостоятельно изучать английский язык. Но вот вопрос, а как оценить свой уровень при самостоятельном изучении? Понятно, что есть IELTS и TOEFL, но эти тесты почти никто не сдает без дополнительной подготовки и эти тесты, как говорят, оценивают не сколько уровень владения языком, а скорее умение проходить эти самые тесты. Да и использовать их для контроля самообучения будет накладно.

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

9 декабря вышла очередная версия Kubernetes — 1.17. Ее девиз — «Стабильность», множество фич получили статус GA, некоторое количество устаревших фич было удалено…

И, как всегда, наш любимый раздел Action Required файла CHANGELOG-1.17.md требует к себе внимания.

Поработаем руками…

Что такое магия в PHP? Обычно под этим подразумевают методы вроде _construct() или __get(). Магические методы в PHP — это лазейки, которые помогают разработчикам выполнять удивительные вещи. В сети полно инструкций по их использованию, с которыми вы наверняка знакомы. Но что если мы скажем, что вы даже не видели настоящую магию? Ведь, чем больше вам кажется, что вы знаете все, тем больше магии ускользает от вас.



Давайте отбросим установленные рамки правил ООП и сделаем невозможное возможным в школе магии PHP. Главный и первый волшебный преподаватель школы — Александр Лисаченко (NightTiger). Он научит магическому мышлению и, возможно, вы полюбите магические методы, нестандартные способы доступа к свойствам, изменение контекстов, аспектно-ориентированное программирование и потоковые фильтры.

Механизм расчета заработной платы в SAP HCM является надежным и в то же время гибким инструментом. Этот инструмент позволяет учитывать любые требования законодательства и локальных нормативных актов в области вознаграждения сотрудников. Однако обратной стороной медали такой универсальности являются сложность и сильная чувствительность к изменениям настроек.

В Хеллоуин положено говорить о страшном, поэтому сегодняшний наш блог – о современной российской фантастике.

Профессиональные писатели-фантасты, как известно, вымерли в России где-то во второй половине 2011 года, когда в издательствах все начало сыпаться к чертям собачьим. Продажи «художки» тогда резко просели, причем практически по всем позициям, за исключением детской литературы. Издатели схватились сначала за голову, потом за карман, и, неоптимистично позвенев мелочью, обратились к народу.

Большинству издаваемых ими авторов они сказали примерно то же самое, что заявил один вредный дед своему популярному впоследствии внучку: «Ну, Лексей, ты — не медаль, на шее у меня — не место тебе, а иди-ка ты в люди…».

И те пошли. В люди, или еще куда – история умалчивает. Но именно 2012 год выкосил весь подлесок профессиональных писателей от второго эшелона и ниже. Гонорары упали настолько, что «жить с пера» могли себе позволить только звезды первой величины.

Русская фантастика, безусловно, не умерла – ее и дустом вывести непросто, — но писательство перестало быть профессией, став чистой воды хобби.



Однако не прошло и пяти лет, как вымершая было популяция была восстановлена: фантасты-профессионалы воскресли в лучших традициях фениксов и ренессансов. Воскресило их магическое слово «прода».

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

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

Холдинг Modesco — это более 300 инфосайтов и 5 крупных Интернет-сервисов. Проекты регулярно покупаются и продаются. Как вы понимаете, поддерживать качество кода на высоком уровне в данной ситуации физически невозможно. Да и основное внимание программистов, как правило, сосредоточено на самих сервисах. Взломы, shell, заражения сайтов прочими вредоносными штуками… Все это наносит ощутимый вред пользователям и компании. Чтобы избежать этого, частенько приходится искать довольно нестандартные способы для уменьшения рисков.

Прим. перев.: Продолжая недавно затронутую нами тему безопасности Kubernetes в целом и RBAC — в частности, публикуем перевод этого материала от французского консультанта из международной компании Big Data-компании Adaltas. Автор в деталях показывает, как создавать пользователей, наделять их правами и в дальнейшем обслуживать.

Настройка и запуск кластера Kubernetes – это только начало: ведь его необходимо еще и эксплуатировать. Чтобы обезопасить доступ к кластеру, нужно задать идентификационные данные пользователей и грамотно управлять настройками аутентификации и авторизации.

(Иллюстрация взята из блога CNCF — прим. перев.)

Эта статья посвящена тому, как создавать пользователей, используя клиентские сертификаты X.509, и как управлять авторизацией с помощью базовых API-объектов RBAC в Kubernetes. Мы также поговорим о некоторых открытых проектах, упрощающих администрирование кластера: rakkess, kubectl-who-can, rbac-lookup и RBAC Manager.

Полтора года назад, читая работы про уязвимости Meltdown и Spectre, я поймал себя на том, что не очень понимаю разницу между сокращениями i.e. и e.g. Т.е. по контексту вроде бы понятно, но потом вроде бы как-то и не совсем то. В результате я тогда сделал себе небольшую шпаргалку именно по этим сокращениям, чтобы не путаться. И тогда же появилась идея этой статьи.

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

Привет, я Андрей Шальнев, QA Automation Lead в проекте Skyeng Vimbox. В течение года мы с командой занимались оптимизацией процессов автоматического тестирования и сейчас вплотную подошли к ее финальной стадии. А это хороший повод выдохнуть, пересмотреть бэклог и подвести какие-то промежуточные итоги. Для Хабры я решил сделать подборку из десяти наиболее полезных и при этом простых вещей, которые помогли нам справиться с задачей оптимизации автотестов. Надеюсь, статья пригодится QA-командам в растущих компаниях, где старые процессы тестирования уже не справляются с нагрузкой, и вопрос реорганизации встает ребром.

Многие современные языки поддерживают сопоставление с образцом (pattern matching) на уровне языка. Java в данный момент не поддерживает pattern matching, но есть надежды что в будущем все может измениться.

Сопоставление с образцом раскрывают перед разработчиком возможность писать код более гибко и красивее, при этом оставляя его понятным.

Используя возможности Java 8, можно реализовать некоторые возможности pattern matching в виде библиотеки. При этом можно использовать как утверждение так и выражения.

Как увидеть цвет, которого в природе не бывает?



Четыре года назад на Хабре был пост с интересным и полезным видео «Как устроен цвет». Лектор — Дмитрий Николаев, заведующий сектором зрительных систем ИППИ РАН.

Я сделал расшифровку (в меру своего понимания материала), потому что считаю и тему важной и подачу — отличнейшей. Пока набирал текст, чуть не поменял своё φ(λ). Слово спикеру:

Поговорим о математике и геометрии цвета, о том, какие абстрактные структуры заложены в этом слове.

Что такое «цвет» не знает никто.

Цвет — это что-то, о чем говорит человек, наблюдающий и познающий мир с помощью глаза.

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

В физике нет цвета, а есть спектральные свойства излучения.

«Цвет» связан с относительным распределением спектральной энергии, мощности или потока излучения. (При прохождении через призму человек видит характерную «радугу».)

Совершенно точно, «цвет» — психологический феномен. Цвет — это ощущение, к объективной физике не имеющий отношения.

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

HighLoad++ существует давно, и про работу с PostgreSQL мы говорим регулярно. Но у разработчиков все равно из месяца в месяц, из года в год возникают одни и те же проблемы. Когда в маленьких компаниях без DBA в штате случаются ошибки в работе с базами данных, в этом нет ничего удивительного. В крупных компаниях тоже нужны БД, и даже при отлаженных процессах все равно случаются ошибки, и базы падают. Неважно, какого размера компания — ошибки все равно бывают, БД периодически обваливаются, рушатся.



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


О спикере: Алексей Лесовский (lesovsky) начинал системным администратором Linux. От задач виртуализации и систем мониторинга постепенно пришел к PostgreSQL. Сейчас PostgreSQL DBA в Data Egret — консалтинговой компании, которая работает с большим количеством разных проектов и видит много примеров повторяющихся проблем. Это ссылка на презентацию доклада на HighLoad++ 2018.

Если верить немецким рекрутерам и нанимающим менеджерам, то проблемы с резюме — основное препятствие на пути к работе в европейской стране для русскоязычных соискателей. CV пестрят ошибками, не содержат нужной работодателю информации и не отражают, как правило, высоких технических навыков кандидатов из России и СНГ. В итоге все выливается в коверную рассылку сотен заявок, 2-3 приглашения на собеседования и быстро возникающее недовольство новым работодателем, даже если контракт заключен и переезд состоялся.

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

Дано: Компания, использующая фреймворк Scaled Agile (SAFe) для масштабирования Agile-разработки в рамках всей организации; 10 команд разработки, объединённых в одну большую команду (Agile Release Train, согласно терминологии SAFe), доставляющую общий продукт; необходимость проведения двухдневного квартального планирования (PI Planning) для определения плана работы ИТ-команд на ближайшие 3 месяца*; три офиса разработки, расстояние между самыми удалёнными превышает 6 тысяч километров с соответствующей разницей в 5 часов рабочего времени; предыдущий опыт планирования, предусматривавший физическое присутствие ключевых коллег в одном помещении и использование аналоговых досок/вайтбордов/маркеров/липких бумажечек.

* Тяжеловесный конструкт “План работы ИТ-команд на ближайшие 3 месяца” грозит серьёзно увеличить объем текста, поэтому в дальнейшем я планирую вместо него писать просто – “коммитмент”. Соответственно, составить и принять план работы – “закоммититься”.

Зачем это понадобилось?

1) Усталость от аналоговых методов работы. В то время, как космические корабли бороздят просторы, а Илон Маск роет тоннели, мы, «айтишники», упорно пишем маркерами на липучих бумажках и лепим их на доски – есть в этом некий диссонанс. Так выглядел наш коммитмент некоторое время назад: