В продолжение темы модельно ориетированного проектирования, публикую очередную статью Калачева Юрия Николаевича, автора книги Моделирование в электроприводе. Инструкция по пониманию. Данный текст еще готовится к публикации в специализированных изданиях, но читатели хабра увидят его первые.
В зарубежной литературе можно встретить два термина, связанных с этими двигателями:
PMSM (Permanent Magnet Synchronous MotorЧитать полностью »
Сервисы падали, падают и будут падать
Когда вы быстро растете, микросервисы начинают появляться буквально по щелчку пальцев и в самых неожиданных местах. В таких условиях каждая команда обычно на ходу решает, где, как и какие логи будет складывать. Когда сначала 10, потом 20, а там и более команд логируют по-своему, начинается хаос.
Например, наша команда сопровождения маркетинга в Skyeng знала: пользователь с таким-то айдишником нажал в личном кабинете кнопку «Сменить преподавателя» — постучался в наш сервис, дальше ушло три сообщения, в очереди было 2 вызова сервисов и эти сервисы ответили 200. Но на самом деле, что было у команд сопровождения учителей или биллинга, к которым мы стучались, не знал никто…
С увеличением количества обслуживаемых продуктов наша дизайн-система начала разваливаться. Вырос порог входа для дизайнеров и работать с ней стало труднее. В статье расскажу как мы перешли на модульную архитектуру и не растеряли консистентность.
Вот немного вводных, которые позволят понять, похож наш случай на ваш или не очень.
Есть несколько продуктов.
Один продукт могут делать несколько команд дизайнеров и разработчиков.
Есть Web, Mobile и Desktop.
Есть много легаси и неконсистентности.
Дизайнер в одном продукте может не знать что происходит в другом.
Знакома ли вам такая картина описанная в названии статьи и задумывались ли вы над ответом на этот вопрос. Как ни странно один и тот же ответ может подходить для двух этих различных случаев. И там и там выигрывает тот кто правильно понимает и работает с требованиями. Но если копнуть глубже, то обнаруживается что смысл заложенный в ответ в обеих случаях очень сильно отличается.
Мы отрендерили 1 миллион самых популярных страниц веба, фиксируя все мыслимые метрики производительности, записывая все ошибки и замечая все запрошенные URL. Похоже, таким образом мы создали первый в мире набор данных, связывающий производительность, ошибки и использование библиотек в сети. В этой статье мы проанализируем, что наши данные могут сообщить о создании высокопроизводительных веб-сайтов.
Можно ли превзойти наш анализ? Мы опубликовали наш набор данных на Kaggle, поэтому вы можете обработать данные самостоятельно.
Сегодня распространено мнение о том, что веб почему-то стал более медленным и забагованным, чем 15 лет назад. Из-за постоянно растущей кучи JavaScript, фреймворков, веб-шрифтов и полифилов, мы съели все преимущества, которые даёт нам увеличение возможностей компьютеров, сетей и протоколов. По крайней мере, так утверждает молва. Мы хотели проверить, правда ли это на самом деле, а также найти общие факторы, которые становятся причиной торможения и поломок сайтов в 2020 году.
Общий план был простым: написать скрипт для веб-браузера, заставить его рендерить корневую страницу миллиона самых популярных доменов и зафиксировать все мыслимые метрики: время рендеринга, количество запросов, перерисовку, ошибки JavaScript, используемые библиотеки и т.п. Имея на руках все эти данные, мы могли бы начать задаваться вопросами о том, как один фактор корреллирует с другим. Какие факторы сильнее всего влияют на замедление рендеринга? Какие библиотеки увеличивают время до момента возможности взаимодействия со страницей (time-to-interactive)? Какие ошибки встречаются наиболее часто, и что их вызывает?
Читать полностью »
Желание написать качественный клиент для любимого мессенджера на go зрело давно, но только месяц назад я решил, что время пришло и у меня есть достаточная квалификация для этого.
Разработка все еще в процессе (и полностью open source), но уже пройден увлекательный путь от полного непонимания протокола до относительно стабильного клиента. В серии статей я расскажу, с какими сложностями я столкнулся и как с ними боролся. Приёмы, которые я применил, могут быть полезны при разработке клиента для любого бинарного протокола со схемой.
Начнем с Type LanguageЧитать полностью »
Недавно я наткнулся на историю столь же удивительную, сколь и ужасную:
Один из моих клиентов занимался поддержкой нескольких пенсионных фондов, входящих в сотню лучших по миру. У него была еженочная пакетная задача, которая начала вылетать. Поначалу никто не мог понять, в чём дело. Насколько все помнили, эта пакетная задача никогда раньше не вылетала.
Написавший её человек умер уже 15 лет назад, да и ушёл из компании много десятков лет назад. Программа была не такой большой, однако оказалась непостижимой. Её писали в стиле, отдававшем приоритет вычислительной эффективности, а не простоте чтения. И, разумеется, у неё не было никаких тестов.
Как назло, днём ранее запушили изменение порядка выполнения скриптов, работающих в этом окружении. Все решили, что виновато это изменение. Инженеры откатили всё к предыдущему релизу. К сожалению, это только усугубило проблему.
…
Ещё одна программа, занимающаяся переводом прибыли, должна была уведомлять пользователей, что их вкладов недостаточно для прогнозирования дохода. Заметив, что из первой программы из-за её вылета нет выходных данных, она восприняла эту ситуацию как «все вклады равны 0». Разумеется, она должна была вести себя совершенно иначе. Но никто не знал, что она будет действовать так, поскольку первая программа никогда не вылетала.
…
Я получил от ИТ-директора неожиданное текстовое сообщение. «Простите за беспокойство, у нас огромная проблема. s1X. Можете прилететь сегодня во второй половине дня?» В их терминологии S1X обозначает «хуже, чем уровень серьёзности 1, потому что проблема распространилась на несвязанные с ней части бизнеса».
К счастью, все пенсии были спасены и история окончилась хэппи-эндом. Но нам вряд ли покажется нормальным, что критически важные финансовые системы зависят от древнего ПО, в котором не разбирается никто из ныне живущих людей.
Читать полностью »
Привет.
Наверное, практически все постоянные читатели и авторы сайта знают, что статьи здесь на сайте могут публиковаться как индивидуальными авторами, так и корпоративными аккаунтами. Невольно возникает «детский» вопрос — какие лучше? Какие статьи получают больше оценок и комментариев? К чему ближе корпоративные блоги — к надоедливой рекламе, которую можно лишь пролистать, или к полезной информации? Попробуем разобраться.
Для тех кому интересно, продолжение под катом.
Читать полностью »
Привет.
Заканчивается 2020 год, а значит, настало время подвести статистические итоги и составить уже традиционный рейтинг лучших статей Хабра за этот год. Этот рейтинг не является официальным, данные собираются парсером с помощью Python. Сортируя данные по тем или иным параметрам, можно получать разные выборки, что на мой взгляд, даёт довольно неплохие результаты. Для читателей также может быть интересно перечитать какие-то статьи, которые они пропустили в течении года.
Поехали.
Читать полностью »
Разработка любого достаточно серьезного софта, будь то калькулятор матриц или ИИ беспилотного автомобиля, — это всегда какая-то своя предметная область, определенные технологии, алгоритмы и структуры данных, архитектура кода, процесс разработки и еще много разных умных терминов из мира IT.
В этой статье представлено одно из решений в мире высокой производительности и распределенных систем. Под катом вы найдёте описание всего лишь небольшого ряда задач и проблем, с которыми мы столкнулись, а также некоторые интересные алгоритмы, подходы к построению архитектуры системы, методы оптимизации запросов, ну и немного о процессе разработки и тестирования решения на базе Tarantool — платформы in-memory вычислений с гибкой схемой данных для эффективного создания высоконагруженных приложений.
Читать полностью »
