Приветствуем уважаемых хабровцев в блоге нашей компании!

В течение ближайших 5-7 минут мы постараемся изложить суть и цели существования «Таксолёта».

Всё началось, как это часто бывает, с недовольства. Недовольства сервисом такси как индустрией в целом, так и отдельными службами — в частности. Отсюда пришла идея сделать службу вообще без диспетчеров и с массой интересных возможностей, превратив такое обыденное занятие, как вызов такси — в приятный, удобный, очень индивидуальный и выгодный сервис.
А всвязи со всесторонним интересом к деятельности нашей компании и активными просьбами людей об открытии «Таксолёта» в различных городах России и Украины, прибавилась еще одна цель — сделать сервис глобальным.

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

Привет всем хабропланетянам!

Сегодня я расскажу вам про киевский сервис интернет заказа такси uklon.com.ua — полностью автоматизированном сервисе, в котором заказ делают клиенты без участия диспетчеров.

Сегодня я расскажу о новой возможности киевского сервиса uklon.com.ua — мобильном заказе, который позволяет делать заказ в несколько фирм такси с телефона, используя java приложение.

«Назвать себя К. не решался, перед телефоном он чувствовал себя беспомощным, на него могли наорать, бросить трубку; К. закрыл себе немаловажный путь. Нерешительность К. раздражала его собеседника. «Кто говорит? — повторил он и добавил: — Я был бы очень обязан, если бы оттуда меньше звонили, только что нас уже вызывали»».

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

Многие из вас слышали о финском бизнес-акселераторе StartupSauna startupsauna.com/ru. Наша команда Такси Джет jettaxi.mobi прошла отбор из 200 команд в России и сейчас находится в Хельсинки. Хочу поделиться своими личными впечатлениями от программы.

Здравствуй, Хабр!

Мы знаем о том, что на Хабре — максимальная концентрация технических специалистов, от начинающих до профи. Само собой, ИТ — сфера, где работают творческие люди, ведь даже для прокладки сетевого кабеля нужен нестандартный подход (вспомним таксу-кабелеукладчик). Ну, а при создании сервиса или десктопной программы нужны свежие мысли, творчество в чистом виде.

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

Немецкий суд постановил запретить использование сервиса Uber водителям, не имеющим лицензии таксиста. За каждое нарушение компании придётся заплатить штраф в размере €250'000. Именно таким образом коллегия из трёх судей выразила свою поддержку местным таксопаркам. Uber заявили, что продолжат предоставлять услуги силами лицензированных таксистов и водителей лимузинов. Компания занимается разработкой дополнений к сервису, которые помогут ей работать в условиях немецкого законодательства.

In this first part of an article series «Citymobil — a manual for improving availability amid business growth for startups» I’m going to break down the way we managed to dramatically scale up the availability of Citymobil services. The article opens with the story about our business, our task, the reason for this task to increase the availability emerged and limitations. Citymobil is a rapid-growing taxi aggregator. In 2018, it increased by more than 15 times in terms of number of successfully completed trips. Some months showed 50% increase compared with the previous month.

The business grew like a weed in every direction (it still does): there was an increase in server load, team size and number of deployments. At the same time the new threats to service availability emerged. The company faced a task of the most importance — how to increase availability without compromising company growth. In this article, I’ll talk about the way we managed to solve this task in a relatively short time.

This is a second article out of a series «Citymobil — a manual for improving availability amid business growth for startups». You can read the first part here. Let’s continue to talk about the way we managed to improve the availability of Citymobil services. In the first article, we learned how to count the lost trips. Ok, we are counting them. What now? Now that we are equipped with an understandable tool to measure the lost trips, we can move to the most interesting part — how do we decrease losses? Without slowing down our current growth! Since it seemed to us that the lion’s share of technical problems causing the trips loss had something to do with the backend, we decided to turn our attention to the backend development process first. Jumping ahead of myself, I’m going to say that we were right — the backend became the main site of the battle for the lost trips.

This is the next article of the series describing how we’re increasing our service availability in Citymobil (you can read the previous parts here and here). In further parts, I’ll talk about the accidents and outages in detail. But first let me highlight something I should’ve talked about in the first article but didn’t. I found out about it from my readers’ feedback. This article gives me a chance to fix this annoying shortcoming.

This is the next article of the series describing how we’re increasing our service availability in Citymobil (you can read the previous parts here: part 1, part 2, part 3). In further parts, I’ll talk about the accidents and outages in detail.

1. Bad release: database overload

Let me begin with a specific example of this type of outage. We deployed an optimization: added USE INDEX in an SQL query; during testing as well as in production, it sped up short queries, but the long ones — slowed down. The long queries slowdown was only noticed in production. As a result, a lot of long parallel queries caused the database to be down for an hour. We thoroughly studied the way USE INDEX worked; we described it in the Do’s and Dont’s file and warned the engineers against the incorrect usage. We also analyzed the query and realized that it retrieves mostly historical data and, therefore, can be run on a separate replica for historical requests. Even if this replica goes down due to an overload, the business will keep running.

This is the final part of the series describing how we’re increasing our service availability in Citymobil (you can read the previous part here). Now I’m going to talk about one more type of outages and the conclusions we made about them, how we modified the development process, what automation we introduced.

Сегодня из пустых пивных банок и старых покрышек мы соберём телеграм-бота для такси. С его помощью можно будет вызывать такси нажатием всего лишь двух кнопок. Вернее так: при первом использовании потребуется нажать три кнопки, а затем всегда — только две. Код написан на Node.js (т.е. ECMAScript, aka JavaScript), без использование каких-либо бот-фреймворков или бот-библиотек — только натуральный продукт — Telegram Bot API. Количество кода указано в названии статьи, выполняется он в Яндекс.Облаке, а точнее в Cloud Functions, а состояния и данные хранятся в Firebase, вернее в Cloud Firestore. Ну а заявки на такси наш скромный бот отправляет в CRM Битрикс24. Как видите — задействованы все! На самого бота можно посмотреть на комиксах ниже, а кликнув по картинке-ссылке под комиксами — открыть и проверить в деле.

Добрый день. Меня зовут Никита Башун, работаю дата-аналитиком в группе компаний «Везёт». Мой рассказ будет о том, как мы командой из трёх человек с нуля создавали систему антифрода для сервиса заказа поездок.

(source)

Translated into English with the help of ChatGPT, link to the original article.

I recently published a series of articles titled 'As Cheap as a Bus, as Convenient as a Taxi...':

1) «Preliminary Analysis»
2) «Experiments on the Torus»
3) «Practically Significant Solutions»
(these articles are currently available only in Russian)

dedicated to making public transportation in large cities completely seamless, without the need for transfers. In the last article of the series, I extensively described a microbus movement scheme that allows them to operate almost like taxis while accommodating 5-10 passengers at once. Such a transportation system would enable city residents to travel from any intersection to another without any transfers, comparable in time to a personal car journey, and at a cost similar to a regular city bus ticket. However, the feedback from readers indicated that I chose an extremely ineffective way to convey the information, resulting in a failure to effectively communicate the essence of the matter.

I must admit that the previous three articles were written in a way that allowed readers to apply the acquired knowledge in practice or continue the research I started on their own. Unfortunately, my desire to 'teach' resulted in nearly 100 pages of complex mathematical text, which is clearly excessive for readers who simply wanted to familiarize themselves with the idea. Here, I will attempt to rectify this mistake and briefly, yet simply, explain the bus taxi technology.