Я стратегический партнер Яндекса. В 2022-м открыл свой таксопарк в Сочи, у нас 40 машин для тарифа комфорт, из них 11 электрокаров и виртуальный парк (подключашка) на 300 водителей. Я слышал, что бизнес в сфере такси — прибыльное дело и мне захотелось рассказать, как здесь обстоят дела на самом деле.

Оговорюсь, что я не испытываю лютой ненависти к корпорации Яндекс. Все‑таки не жадный монополист подмял рынок. Яндекс сделал удобное приложение, и сами пользователи подмялись под него, а вслед за ними водители и таксопарки. Но есть нюансы.

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

Всем привет! Меня всё ещё зовут Антон. В предыдущей  статье я провел небольшой обзор APIM Gravitee и в целом систем типа API Management. В этой статье я расскажу, как поднять ознакомительный стенд APIM Gravitee (https://www.gravitee.io), рассмотрим архитектуру системы, содержимое docker compose file, добавим некоторые параметры, запустим APIM Gravitee и сделаем первую API. Статья немного погружает в технические аспекты и может быть полезна администраторам и инженерам, чтобы начать разбираться в системе.

Всем привет! Меня зовут Антон, я – инженер команды, отвечающей за развитие централизованных IT-сервисов, которыми пользуются продуктовые команды в X5 Retail Group.

В этой статье я расскажу о системах класса API Management и в частности о APIM Gravitee (https://www.gravitee.io), том, что это за класс систем, как они используются для обеспечения потребностей команд разработки. Статья не погружает в технические аспекты, но может быть полезна архитекторам и менеджерам, которые думают о том, чтобы попробовать использовать данный класс систем, но не знают, подойдут ли они для их задач, а также разработчикам, которые могут открыть для себя новые инструменты для удобной работы с API.

Меня зовут Юрий Шуткин, я инфраструктурный инженер в Тинькофф. В этой статье расскажу, как мы запустили сервис по хранению важной информации и избавились от небезопасной передачи секретов. 

Секретами мы называем важную информацию, которую нельзя хранить в открытом виде: пароли, токены, сертификаты.

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

Четыре года назад я совершил один из самых безрассудных поступков в своей жизни: начал учить японский язык. Разумеется, прежде чем решиться на такое приключение, я тщательно все продумал и провел подробное исследование на тему. Т.е. погуглил, что другие люди думают об этом экзотическом языке. Отзывы меня весьма приободрили. В них говорилось, что нужны годы и годы тяжелого учения. Люди писали, что, если тебе кажется, что язык очень тяжелый, то ты все еще недооцениваешь опасность раз в десять. Интернет пестрит предупреждениями, что тебе это не нужно; что это тяжело; что "не лезь оно тебя сожрет".

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

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

Привет! Меня зовут Иван Гаас, я руковожу автоматизацией процессов разработки в Почтатехе — компании, создающей цифровые продукты для Почты России.

Среднее количество сообщений, которые мы обрабатываем в Почте — от 500 тысяч до миллиона в секунду. В пики, когда наша big data прогоняет свои 25 петабайт данных — до 3 миллионов. При этом кластер Kafka состоит всего из 12 серверов в каждом из 3 дата-центров и справляется с этим.

C 2016 года мы в три раза увеличили количество новых цифровых сервисов. Корпоративная шина на Kafka помогла быстро масштабироваться: количество интеграций за последнее время упало с 1000 до 300 и теперь растёт незначительно. Если раньше интеграция сервиса растягивалась на месяцы, то теперь достаточно нескольких дней.

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

Event system architecture (EDA)

Ещё одна из популярных архитектур — Event system architecture (EDA), что в переводе на русский означает “архитектура на основе событий”. Суть данной архитектуры состоит в том, что приложение работает с событиями (эвентами), которые генерируются пользователем или другими системами.

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

Monolite or MicroService ?

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

Давайте для начала разберём что такое монолит и его преимущества и недостатки.

Всем привет. Меня зовут Тетка Андрей, я занимаюсь программированием уже больше 10 лет и за это время несколько раз приходилось разрабатывать архитектуру как крупных проектов, так и не больших фич. Я когда то уже делал вебинар на эту тему, но сейчас хотелось бы всё систематизировать и рассказать об этом вам.

И прежде чем мы начнем проектировать архитектуру, давайте сначала ответим на вопрос, а что же собственно такое архитектура?

Нилу Роузману уже порядком надоело слушать, как компании Кремниевой долины говорят, будто нанимают «только самых лучших и самых способных». Неважно, сколько раз они это повторяют, большинство компаний по-прежнему принимают решения, основываясь на интуиции, дипломе соискателя, его среднем балле, образовании, полученном в Лиге плюща, броских именах прошлых работодателей и даже на баллах SAT. Роузман против такого подхода. Будучи вице-президентом по технологиям в Amazon и Zynga, он провел сотни собеседований и считает, что каждый этап процесса должен быть тщательно проработан, поскольку необходимо тщательно изучить навыки, реальные достижения, соответствие кандидата требованиям корпоративной культуры и его лидерский потенциал.

Меня зовут Илона, я Senior Experience Designer в EPAM. Работа для меня удачно совпадает с хобби — в EPAM я проектирую интерфейсы для зарубежных заказчиков, читаю лекции для сотрудников и студентов лабы, менторю дизайнеров. В свободное время преподаю проектирование интерфейсов в магистратуре Университета ИТМО и веду Телеграм-канал о UX-дизайне.
В работе и преподавании я часто сталкиваюсь с проблемой: сложно организовать компоненты интерфейса так, чтобы было всегда понятно, какой компонент использовать, чтобы похожие компоненты не плодились и не путали дизайнеров и разработчиков.
Делюсь подходом, который помогает мне удобно организовать компоненты и упростить жизнь себе и разработчикам.

• начну писать код, а в процессе пойму, что да как;
• почитаю форумы, хабр, medium, stack overflow, книгу, записи на стенах, знаки свыше…;
• поспрашиваю у коллег, может, кто-то знает, как решить подобную задачу;
• начну рисовать квадратики и схематично покажу, какое видение задачи сформировалось у меня в сознании.

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

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

⭐ градиент обреченный

В задачах распознаваниях речи при переводе аудио в текст есть дополнительные этапы, делающие этот текст более человекочитаемым. Например, предложение "привет хабр сегодня мы сделаем двадцать шесть моделей по распознаванию голоса" будет выглядеть лучше в таком виде: "Привет, хабр. Сегодня мы сделаем 26 моделей по распознаванию голоса". Другими словами, сегодня мы поговорим про то, как автоматически восстановить пунктуацию и капитализацию (сделать нужные буквы заглавными). Также упомянем денормализацию текста (при этом числа обретут свою цифровую форму обратно, эту задачу еще называют inverse text normalization).

Пунктуация и капитализация

Вчера понадобилось мне записать голос для голосового (IVR) меню. Решил воспользоваться голосами от яндекс.облака, тем более что они теперь все высококачественные, и от человеческого неотличимы. Но как бы это сделать поудобнее, чтобы не надо было потом редактировать и конвертировать? Казалось бы, можно воспользоваться демкой на странице описания, но во первых там есть ограничение длины текста, во вторых она дает сохранить только запись в формате ogg, и в третьих иногда добавляет в запись рекламу. Оно и понятно в общем то, эта демка предназначена для показа технологии а не для коммерческого использования.

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

Беглый гуглёж ничего не принес, только несколько малопонятных проектов на гитхабе.

Уже думал быстренько наваять какой нибудь свой веб-интерфейс но тут вспомнил что есть Postman. Для тех кто не в теме - это замечательная программа для тестирования любых api интерфейсов.

Под катом - как настроить Postman для преобразования текста в речь.

Вашему вниманию предлагаю перевод статьи Sacha Greif "Что же такое этот GraphQL?"

Если вы такой же, как и я, вы обычно проходите через три этапа, когда узнаёте о новой технологии:

• Отрицание: Ещё одна JavaScript библиотека?! Зачем? У меня уже есть jQuery!
• Интерес: Хм, наверное мне следует взглянуть на эту библиотеку...
• Паника: Помогите! Мне нужно изучить эту библиотеку прямо сейчас, иначе мои знания устареют!

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

Именно поэтому сейчас самое время узнать, что же такое этот GraphQL, о котором вы повсюду слышите.