В прошлый раз мы рассмотрели два подхода к работе с микросервисами. В частности, один из них подразумевает применение контейнеров Docker, в которых можно выполнять код микросервисов и вспомогательных программ. Сегодня же мы, используя уже имеющиеся у нас образы контейнеров, займёмся работой с Kubernetes.

По нашей просьбе Хабр создал хаб Kubernetes и нам приятно разместить первую публикацию в нём. Подписывайтесь!

Kubernetes — это просто. Почему же банки платят мне за работу в этой сфере большие деньги, в то время как любой может освоить эту технологию буквально за несколько часов?

TypeScript — стандарт современной фронтенд-разработки. Согласно исследованиям State of JavaScript, TS вызывает явный интерес у программистов. По данным опроса за 2019 год, почти 60% респондентов пробовали TS и продолжают использовать, 22% не пробовали и желают изучить.

Эта статья — сборник советов о том, как внедрить и улучшить использование TypeScript. Первая половина советов общая, касающаяся подходов и инфраструктуры. Вторая — несколько особо полезных фишек языка.

Статья подготовлена с коллегами, занимающимися установкой систем усиления сотовой связи https://t.me/usileniesvyazi.

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

Существует два основных варианта усиления сотовой связи:

1. С помощью антенны, модема и роутера.
2. С помощью активного усилителя (репитера).

Первый вариант для усиления интернета 3G/4G/5G, не усиливает голосовую связь в обычном для нас формате (но можно пользоваться звонками через мессенджеры: WhatsApp, Viber, Skype, Telegram).

Второй вариант универсальный – усиливает интернет и голосовую связь, но имеет ряд ограничений (о ограничениях ниже).

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



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

Кажется, тема «зачем нужен Kubernetes», уже раздражает. Хочется сказать: «все кому надо — давно уже поняли», однако я разделил бы технических (и околотехнических) работников на тех, кто «понял и знает как использовать», и тех, кто «понял, но хочет знать, как сделать знания актуальными».

Возможно, вы менеджер, который последние 10 лет работал на одном и том же стеке; возможно, вы разработчик, который поддерживает старое решение или пишет на привычном языке в привычной среде. Возможно, вы просто перешли из технического в организационный менеджмент и вдруг выяснили, что все, что вы знали, больше не актуально, и хочется понять — есть ли какой-то относительно простой сценарий, как это можно догнать. Я постараюсь дать советы, основываясь на собственном опыте, — от человека, который осознал, что, находясь на организационном управлении, скоро будет выражаться словами «Kubernetes — это эффективная технология, мы должны стремиться к ее применению», не вполне понимая, что лежит за этими словами и за всей технической культурой, развившейся в последнее время.

Почему я считаю важным уметь менять парадигму технологического мышления?

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

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



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

Доброго времени суток, друзья!

Вероятно, многие из вас слышали о таком новшестве в экосистеме JavaScript, как сервис-воркеры (Service Workers), которые являются ключевым элементом современной веб-разработки. Сервис-воркеры становятся все более востребованными, в первую очередь, благодаря популярности прогрессивных веб-приложений (Progressive Web Applications — PWA).

Когда я впервые услышал о них, я задался вопросом: «Когда мы должны использовать сервис-воркеры? В каким сценариях или контексте мы можем их использовать?»

В данной статье мы рассмотрим несколько практических примеров использования сервис-воркеров, что впоследствии, смею надеяться, сделает счастливыми ваших пользователей.

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

Доброго времени суток, друзья!

Представляю вашему вниманию перевод статьи «JavaScript Visualized: Promises & Async/Await» автора Lydia Hallie.

Приходилось ли вам сталкиваться с JavaScript кодом, который… работает не так, как ожидается? Когда функции выполняются в произвольном, непредсказуемом порядке, или выполняются с задержкой. Одна из главных задач промисов — упорядочение выполнения функций.

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

Хабра-сообщество провело еще одно интервью в нашем образовательном проекте: прямых эфирах c ребятами из IT, которые отвечают на ваши вопросы в формате живого общения.

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

В начале недели наши вопросы отвечал Борис Янгель — ML-инженер Яндекса, который участвовал в создании мозгов «Алисы», а теперь делает беспилотные автомобили. 

Боря рассказал о том, как стать крутым Data-Scientist, как парашютный спорт помогает ему в работе, почему конференции по ML бесполезны и ответил на недавний пост разгневанного отца про то, как Алиса рекомендовала видео с историями убийств ребенку.

Наша компания с 2008 года занимается преимущественно управлением инфраструктурами и круглосуточной технической поддержкой веб-проектов: у нас более 400 клиентов, это порядка 15% электронной коммерции России. Соответственно, на поддержке очень разнообразная архитектура. Если что-то падает, мы обязаны в течение 15 минут это починить. Но чтобы понять, что авария произошла, нужно мониторить проект и реагировать на инциденты. А как это делать?

Я считаю, что в организации правильной системы мониторинга происходит беда. Если бы беды не было, то мой спич состоял из одного тезиса: «Установите, пожалуйста, Prometheus + Grafana и плагины 1, 2, 3». К сожалению, теперь так не работает. И главная проблема заключается в том, что все продолжают верить во что-то такое, что существовало в 2008 году, с точки зрения программных компонентов.

В отношении организации системы мониторинга я рискну сказать, что… проектов с грамотным мониторингом не существует. И ситуация настолько плохая, если что-то упадёт, есть риск, что это останется незамеченным — все ведь уверены, что «всё мониторится».
Возможно, всё мониторится. Но как?

Все мы сталкивались с историей наподобие следующей: работает некий девопс, некий админ, к ним приходит команда разработчиков и говорит — «мы зарелизились, теперь замониторь». Что замониторь? Как это работает?

Ок. Мониторим по старинке. А оно уже изменяется, и выясняется, что ты мониторил сервис А, который стал сервисом B, который взаимодействует с сервисом C. Но команда разработчиков тебе говорит: «Поставь софт, он же должен все замониторить!»

Так что изменилось? — Всё изменилось!

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

Предлагаю вашему вниманию перевод статьи, написанной инженером из Uber.

* * *

В последние несколько лет я создавал и обслуживал большую распределённую систему платежей в Uber. За это время я многое узнал о концепциях распределённых архитектур и на своём опыте выяснил, насколько трудно создавать и обслуживать высоконагруженные системы с высокой доступностью. Построение такой системы — работа интересная. Мне нравится планировать, как система будет обрабатывать рост трафика в 10-100 раз, обеспечивать надёжность данных вне зависимости от аппаратных сбоев. Однако эксплуатация большой распределённой системы дала мне неожиданный опыт.

За 3 последних года в Контуре случилось больше тысячи инцидентов разной степени эпичности. Причины разные: например, 36% вызвано некачественным релизом, а 14% — работами по обслуживанию железа в дата-центре. Откуда статистика? После каждого инцидента пишется отчёт — постмортем. Их пишут дежурные инженеры, которые отреагировали на уведомление об аварии и первыми начали разбираться в ее причинах. Постмортемы анализируются, выявляются и устраняются причины инцидентов, чтобы в дальнейшем подобные инциденты не возникали. Но так было не всегда.

Алексей Кирпичников (BeeVee) с 2008 года программировал в Яндекс. Пробки, работал над спортивными спецпроектами, был тимлидом команды бэкенда Яндекс.Такси. С 2014 года занимается DevOps и инфраструктурой в Контуре — разрабатывает инструменты, которые облегчают жизнь разработчиков из продуктовых команд. Идея писать и анализировать постмортемы появилась пять лет назад, и за это время постмортемы обросли шаблонами, глоссарием, памятками, скриншотами и аналитикой. Но не это самое сложное — труднее было преодолеть инертность, страхи и непонимание смысла отчетов об инцидентах среди инженеров. Что в итоге получилось и какую непоправимую пользу может нанести «диванная аналитика» — в расшифровке доклада Алексея.


Обратите внимание — под ножки стола разной длины подложены книжки «Метрики», «Тесты» и «Деплой».

Linux — это операционная система. Как винда (windows), только более защищенная. В винде легко подхватить вирус, в линуксе это практически невозможно. А еще линукс бесплатный, и ты сам себе хозяин: никаких тебе неотключаемых автообновлений системы!

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

Я дам кратенькое описание основных команд с примерами (примеры я все проверяла на cent os, red hat based системе) + ссылки на статьи, где можно почитать подробнее. Если же хочется копнуть еще глубже, то см раздел «Книги и видео по теме». А еще комментарии к статье, там много полезного написали)

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

Тогда, в начале времен, все эти команды и функции далеко опережали свое время, и благодаря им Asterisk "уделывал" по функционалу многие коммерческие продукты.

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

Но разработку модуля Астериск на языке С сложно назвать тривиальной задачей. Это весьма тернистый путь, к тому же весьма рискованный, ведь критическая ошибка в своем модуле запросто приводила к полному падению Asterisk в core.

Нужны были более "мягкие" и простые способы для расширения функций и интеграции с другими системами.

Так появились интерфейсы AGI и AMI.

В апреле инженеры Авито собирались на онлайн-посиделки с главным разработчиком ClickHouse Алексеем Миловидовым и Кириллом Шваковым, Golang-разработчиком из компании Integros. Обсуждали, как мы используем систему управления базами данных и какие сложности у нас возникают.

По мотивам встречи мы собрали статью с ответами экспертов на наши и зрительские вопросы про бэкапы, решардинг данных, внешние словари, Golang-драйвер и обновление версий ClickHouse. Она может быть полезна разработчикам, которые уже активно работают с СУБД «Яндекса» и интересуются её настоящим и будущим. По умолчанию ответы Алексея Миловидова, если не написано иное.

Осторожно, под катом много текста. Надеемся, что содержание с вопросами поможет вам сориентироваться.

Представляем вашему вниманию перевод статьи, посвящённой использованию атрибутов data-*. Это — атрибуты, которые можно применять для удобного хранения в стандартных HTML-элементах различной полезной информации. Эта информация, в частности, может применяться в JavaScript и CSS.

Одно из решений, которые приходится принимать фронтенд-разработчику при создании сайта, касается выбора способа включения изображений в состав веб-страниц. Этот способ может заключаться в использовании HTML-тега <img>. Это может быть применение CSS-свойства background или тега <image> элемента <svg>. Выбор правильного подхода к работе с изображениями весьма важен, так как это может очень сильно повлиять на производительность и доступность проекта.



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

Если вы занимаетесь веб-разработкой, вы, вероятно, слышали о Svelte Js. Тем не менее, думаю, вам будет интересно, почему он набирает популярность и какими интересными преимуществами для веб-разработчиков обладает.

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

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


Эта статья посвящена всему, что нужно знать о настройке расстояний между элементами и о настройке внутренних пространств элементов. В частности, речь пойдёт о том, в каких ситуациях стоит использовать внутренние отступы (padding), а в каких — внешние (margin).