Наделяем наш медиацентр еще одной возможностью - управление торрент-клиентом и его загрузками из мессенджера Telegram через чат-бота. Теперь вы не будете ограничены лишь локальной домашней сетью. Управлять загрузками на домашнем сервере из любой точки мира? Легко!

За 21 год существования в SuperJob разработали три версии реализации API для интеграций с бэкендом. Во время разработки последней они решили пересмотреть подход к версионированию. Сейчас в актуальной реализации порядка 379 эндпойнтов, более 900 моделей сущностей и 11 поддерживаемых мажорных версий. Когда проект развивается, вместе с ним меняются и требования к API, а значит неизбежно нарушение обратной совместимости.

Опытом решения этой проблемы поделился Антон Золотилин из SuperJob. Вы увидите самые распространенные решения проблемы версионирования web-API и подход, который реализовал у себя SuperJob. А в качестве бонуса узнаете, как это решение помогает значительно сократить рост затрат на тестирование версий с помощью Impact-анализа.

Есть исследование от Google, которое говорит, что если ваш сайт открывается больше трех секунд, то вы потеряете около 40% десктопных пользователей и более 50% — мобильных. Еще есть репорт от Amazon, который говорит, что для Amazon каждые 100 мс дополнительного latency стоит им 1% продаж. В объемах Amazon это миллионы долларов.

В зависимости от вашего бизнеса вам стоит тоже ответить на вопрос: Does the latency matter?

Я работаю как системный инженер уже более 8 лет. Хочу поделиться опытом, который получил в процессе решения задач в компании Big Data Technologies. У нас есть какой-никакой highload. В пике это 30 тысяч rps, и вопрос с latency довольно остро стоит перед бизнесом.

Спор «фуллстек против узкой специализации» вечный. Но одно дело — спорить в комментах, а совсем другое — создать собственную компанию и проверить экстремальный подход на практике. Антон Кекс пошел по этому пути: стал сооснователем компании Codeborne, где разработкой занимаются исключительно «фуллстек-крафтсмены» и практикуется экстремальное программирование. И по его словам, там командами из 2-4 человек получается сделать то, на что другим требуется человек 50.

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

Можно не соглашаться с его позицией, но как минимум ознакомиться с ней полезно. И хотя доклад сделан еще пару лет назад, в 2021-м он продолжает собирать просмотры, поэтому мы решили сделать для Хабра текстовую версию. Под катом — и видеозапись, и текстовая расшифровка. Дальше повествование ведется от лица Антона.

Vuex — это потрясающая библиотека управления состояниями. Она проста и хорошо интегрируется с Vue. Зачем кому-то уходить от Vuex? Причина может быть в том, что предстоящий релиз Vue 3 раскроет заложенную в ее основе систему реактивности и предложит новые способы структурирования приложения. Новая система реактивности настолько мощная, что это можно использовать для централизованного управления состояниями. 

.       .       .      

Нужно ли вам общее состояние?

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

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

В данной статье не будут "размусолены" принципы работы и тонкости Push уведомлений, только код

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

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

Как появился Пегас?

Величайшим из древнегреческих философов по праву считается ученик Сократа афинянин Платон. Именно благодаря его "Диалогам" до нас дошла большая часть сведений о греческой философской мысли.

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

Основной идеей философии Платона была, извините за каламбур, сама "идея". Именно он ввел в оборот это слово, которое на древнегреческом звучало как "эйдос". Для объяснения своей теории Платон обычно использовал аллегорию, позже ставшую известной как миф о пещере. Я вкратце приведу здесь только самую ее суть.

Представьте себе абсолютно пустую белую комнату. В этой комнате нет дверей, на одной из стен почти под потолком располагается единственное окно. Под этим окном стоит кресло, к которому железными цепями крепко-накрепко привязан человек. Его голова и тело зафиксированы таким образом, что единственное, что он видит - противоположную от окна стену. Этот человек в раннем детстве был похищен учеными, подключен к системам жизнеобеспечения и привязан цепями к своему креслу, он вырос в этой комнате и никогда не видел мира за ее пределами. Время от времени ученые проносят за окном какие-то предметы: статуи, изображения животных, растений, зданий. Узник не видит самих предметов, а видит лишь только тени, отбрасываемые ими на противоположную от окна стену комнаты. Он различает в этих тенях схожие паттерны и дает им названия. Узник искренне считает, что те тени на стене, что он видит и которым дает имена - реальны.

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

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

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

Сегодня, специально к старту нового потока по веб-разработке, поделимся с вами туториалом, из которого вы узнаете, как создать видеочат с помощью JavaScript и NodeJS. Также вы научитесь использовать PeerJS, WebRTC и Socket.io.

Практически любая enterprise-система (под которой мы будем подразумевать некоторое ПО, где пользователи работают постоянно в течение всего рабочего дня) в современном мире стремится вырасти вместе с управляемым ей бизнесом в высоконагруженное web-решение вроде нашего СБИС.

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

Когда, где и как их может вызвать затаившийся до поры диверсант?

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

Какие существуют метрики производительности?

Как оценить качество вашего приложения? 

Как поднять метрики? 

Какие инструменты позволяют оценить показатели производительности, и др. 

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

Некоторая... академичность. Разобрано множество идей и концепций, но заканчивается всё стандартным: "ваш выбор зависит от вашей ситуации".

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

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

Кому интересно, прошу под кат.

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

В пике на нашей образовательной платформе проходит до 4 тысяч уроков в час. Основной инструмент общения преподавателя и студента — видеосвязь, потому что для обучения важно видеть и слышать друг друга. В самом начале мы использовали Skype, но его нельзя было интегрировать в платформу и логировать уроки. Потом мы перешли на SaaS-решения, но это оказалось очень дорого. Мы начали искать альтернативы и 2016 году отказались от покупных решений в пользу WebRTC и Janus. Теперь дорабатываем видеоконференции под образовательную платформу силами собственной команды. Да, пришлось копнуть глубже и потоптаться по граблям чужой технологии.
Рассказываем, как мы выкручивались и улучшали видеосвязь, чтобы она не попадала в топ жалоб от клиентов.