Комментарии 96
Что ж за мода такая, «продолжение следует». Вроде бы нету лимита на количество символов в статье?
1)Недостаток мотивации на написание большой статьи
2)Желание собрать комментарии и плюсы два раза
2)Желание собрать комментарии и плюсы два раза
Так а почему сейчас все деньги не в кино, а в сериалах, как вы думаете? (А в кино — в киносериалах).
Что ж за мода такая, в русском языке нет слова «нету»…
Любой язык развивается. Сегодня нету, а завтра — появится. Вон "в смысле" тоже не было, а теперь — в предлоги ввели.
Как минимум, в моем "Словаре русского языка" под ред. Ожегова (1983 года издания) слово "нету" есть, и с тех пор оно никуда не девалось.
ru.wikisource.org/wiki/Я_к_вам_пишу_случайно,_—_право_(Лермонтов)
Лермонтов использовал это слово в своих стихотворениях, а теперь вдруг решили, что слово не существует? Слово зафиксировано в различных словарях: gramota.ru/slovari/dic/?word=%D0%BD%D0%B5%D1%82%D1%83&all=x
Лермонтов использовал это слово в своих стихотворениях, а теперь вдруг решили, что слово не существует? Слово зафиксировано в различных словарях: gramota.ru/slovari/dic/?word=%D0%BD%D0%B5%D1%82%D1%83&all=x
Во-первых, простыни читать не очень удобно
Во-вторых, написать сразу все означает потратить куда больше времени. А так можно посмотреть, если ли интерес у аудитории, и если его нет — время на вторую часть на тратить.
Во-вторых, написать сразу все означает потратить куда больше времени. А так можно посмотреть, если ли интерес у аудитории, и если его нет — время на вторую часть на тратить.
Программистский подход, сделал что-то выкатил тут же.
Ни тесты не написал, ни нагрузочное тестирование не проводил.
Хотя и такие практики в те годы не были распространены.
Хорошо, конечно, что у автора всё получилось, но лучше было хотя бы клиентов-ботов написать, чтобы потестили под нагрузкой.
Хотя и такие практики в те годы не были распространены.
Хорошо, конечно, что у автора всё получилось, но лучше было хотя бы клиентов-ботов написать, чтобы потестили под нагрузкой.
Клиентов ботов, чтобы на машинах по городу колесили под мостами да туннелями? Ну вы слишком много хотите от провинциала-одиночки.
Боты были. Нагрузочное тестирование тоже. Многие моменты опускаю умышленно, дабы не вдаваться совсем в детали. Хотелось все более менее в художественном стиле изложения истории описать, но не забывая про ключевые детали.
custdev скорее, но можно и так назвать, не спорю
Мне кажется на пикабу это зародилось, как попытка минимальными усилиями понять хорошо ли получается, и набрать рейтинга и подписчиков за серию коротких заметок. Плюс специфика ресурса, когда цели написать законченный пост в общем то и не стоит. Я тоже никак не привыкну к этому на техническом хабре (
Вообще-то это нормальный формат, который идёт ещё от серий газетных колонок, периодических изданий и пр.
Формат-то существует, но Хабр набрал свою аудиторию за счет технических статей, где всё рассказывается за раз. И возникла привычка, в контексте хабра, читать всю историю целиком.
У газетных колонок и периодических изданий есть физическое ограничение размеров издания, в цифровом же виде это или намеренный ход для рейтинга, либо отсутствие времени у автора, отчего страдает восприятие истории.
У газетных колонок и периодических изданий есть физическое ограничение размеров издания, в цифровом же виде это или намеренный ход для рейтинга, либо отсутствие времени у автора, отчего страдает восприятие истории.
За модой не гонюсь. Пишу в свободное время.
Звучит интересно, но «… и 2 Казахстана» — это эпик.
Многое читается между строк. Эта автоматизация, какая она и должна быть.
Автор молодец.
Автор молодец.
Такси Максим чтоли? Они тоже на Урале вроде начинались где то.
Сервер БД: MsSQL
А почему вы не использовали SQLite?
хотя
Мне был открыт безлимит в дальнейшем финансировании проекта.
SQLite это как бы не серверная база данных
Запись в один поток и возможные блокировки чтения — проще взять полноценную серверную СУБД. Конкретно MS SQL видимо из-за опыта автора, т.к. в Delphi-мире гораздо чаще Firebird встречается.
ORACLE и MS SQL это 2 относительно дешевые коммерческие базы с очень широкими возможностями. Плюс отлично масштабируются по вертикали. В отличие от других.
Плюс довольно часто вместо усложнения приложения часть бизнес логики переносят в БД.
Плюс довольно часто вместо усложнения приложения часть бизнес логики переносят в БД.
Oracle дешёвый?!
НЛО прилетело и опубликовало эту надпись здесь
Дешевые? Вы ничего не перепутали?
А за перенос логики в БД по рукам бить надо, т.к. потом хрен мигрируешь на другую БД.
А за перенос логики в БД по рукам бить надо, т.к. потом хрен мигрируешь на другую БД.
А за использование только одного языка программирования тоже бить по рукам надо? Иначе как потом мигрировать на другой ЯП.
Что простите? А для чего тогда СУБД с возможностью хранения бизнес логики в виде хранимых процедур?
Абсолютно с вами солидарен насчёт битья по рукам. Особенно нужно бить тех, кто часть логики трансформации данных опускают в БД при живом ETL-средстве, в итоге тебе в базу положили одно, а вытащил ты непонятное нечто. Теория информации подсказывает, что любая обработка информации узлом приводит к её потере. Имеем снижение надёжности интеграции и так или иначе однажды возникновение ошибки о получении недопустимых данных.
бить надо по головам, эникейщикам, которые в СУБД не бум бум. Логика в СУБД существует именно для того чтобы в БД лежало то что должно лежать, а данные предоставлялись именно те которые нужно предоставить. Для этого средствами СУБД реализуются всевозможные API.Если вам не нужно РСУБД, то тогда текстовые файлики или BigData.
В моей практике встречались не раз очень элегантные решение на ХП. Если тоже самое делать на уровне приложения, было бы и неудобнее (больше кода) и медленнее. Почему же вы категорически против такого подхода, только потому, что кто-то его неправильно применяет?
И никто не запрещает, например, всю бизнес логику вынести на уровень БД, если это хорошо подходит под задачу.
И никто не запрещает, например, всю бизнес логику вынести на уровень БД, если это хорошо подходит под задачу.
На моей практике (в т.ч. собственной) элегантные решения встречаются, но вы должны знать, что исключения лишь подтверждают правила. Также, я не утверждал, что против полного переноса логики в БД.
Итак, о чём было утверждение: частичный перенос логики на уровень БД при наличии интеграционного уровня приложения является хаком или костылём, в большом кровавом энтерпрайзе (а мы ведь про него, правда?) решения должны быть изолированы в пределах своей зоны ответственности (инкапсулированы). Потому что за разные уровни отвечают сильно разные люди и политики, взаимодействия. Я не говорю про стартап-компании, где один специалист — и чтец, и жнец, и на дуде игрец, я про серьёзные большие группы.
Отсюда следует, что решение может быть как полностью в БД, так и полностью в интеграционном слое. Все современные топ-ETL средства (Informatica, ODI, etc) покрывают все необходимые задачи, и если подпорку опускают в БД, значит, специалист плохо знает свой ETL-продукт.
Итак, о чём было утверждение: частичный перенос логики на уровень БД при наличии интеграционного уровня приложения является хаком или костылём, в большом кровавом энтерпрайзе (а мы ведь про него, правда?) решения должны быть изолированы в пределах своей зоны ответственности (инкапсулированы). Потому что за разные уровни отвечают сильно разные люди и политики, взаимодействия. Я не говорю про стартап-компании, где один специалист — и чтец, и жнец, и на дуде игрец, я про серьёзные большие группы.
Отсюда следует, что решение может быть как полностью в БД, так и полностью в интеграционном слое. Все современные топ-ETL средства (Informatica, ODI, etc) покрывают все необходимые задачи, и если подпорку опускают в БД, значит, специалист плохо знает свой ETL-продукт.
Также, я не утверждал, что против полного переноса логики в БД.
А как же это?
Абсолютно с вами солидарен насчёт битья по рукам. Особенно нужно бить тех, кто часть логики трансформации данных опускают в БД…
По моему, вы именно утверждаете, соглашаясь с товарищем vanyas, что за любой перенос этой логики надо наказывать и особенно (наверное, сильнее бить) за частичный.
По рукам бы бить не стал, вполне себе практикуется. Но я вот тоже не люблю, когда бизнес логику не оправданно в БД переносят.
После MS SQL на Oracle чувствовал себя со связанными руками. Одно только отсутствие нормальных времянок было огромным минусом. Как там в последних версиях — не в курсе.
Странный перечень вопросов для выбора технических решений на стадии MVP. Да и далее вы кажется просто взяли то, что знали сами :)
И я так понимаю эти вопросы с обратным приоритетом? Выбор ОС кажется менее приоритетное, чем выбор стека технологий по наличию достаточного количества специалистов?
И сразу хочется узнать, какие из критериев оказались полезные, а какие нет?
Вот выбор бинарного протокола на MVP вам помог?
Авральная работа запоем, поддержка директоров и пользователей это прекрасно, но напишите сразу как этого стоило избежать :)
И я так понимаю эти вопросы с обратным приоритетом? Выбор ОС кажется менее приоритетное, чем выбор стека технологий по наличию достаточного количества специалистов?
И сразу хочется узнать, какие из критериев оказались полезные, а какие нет?
Вот выбор бинарного протокола на MVP вам помог?
Авральная работа запоем, поддержка директоров и пользователей это прекрасно, но напишите сразу как этого стоило избежать :)
НЛО прилетело и опубликовало эту надпись здесь
— Сейчас я бы другими критериями руководствовался. Наверное они покажутся странными. Но тогда именно они были ключевыми;
— Порядок критериев != приеоритету.
— Остаться на MsSQL было верным решением, в плане экономии времени в дальнейшей работе. В противном случае переход на новую бд добавил бы еще больших бессонных ночей :)
— Бинарный протокол теперь уже кажется сомнительным решением. По правде и json простой хорошо бы себя показал;
— Напишу все ошибки, и свои и в целом. Хотел это на последок оставить.
— Порядок критериев != приеоритету.
— Остаться на MsSQL было верным решением, в плане экономии времени в дальнейшей работе. В противном случае переход на новую бд добавил бы еще больших бессонных ночей :)
— Бинарный протокол теперь уже кажется сомнительным решением. По правде и json простой хорошо бы себя показал;
— Напишу все ошибки, и свои и в целом. Хотел это на последок оставить.
В общем история из разряда Русского Бизнеса — а 16 шапок можешь?
Вот это вы зря. Это история из разряда реального бизнеса. Приходится работать с неидеальными инструментами и в неидеальной ситуации. Но на эту тему есть в классике (а на какую нет? :) )
You have to make the good out of the bad because that is all you have got to make it out of. (С) All the King's Men.
You have to make the good out of the bad because that is all you have got to make it out of. (С) All the King's Men.
Это история из разряда реального бизнеса.
"Вот тебе тонна *овна, к завтраму (звук передёргиваемого затвора) приду за конфеткой"?
(Кстати, интересно, в цифре "100+ миллионов" чьих заслуг больше — автора или инфляции? :)
(Кстати, интересно, в цифре «100+ миллионов» чьих заслуг больше — автора или инфляции? :)
Я сейчас банальную вещь скажу. Но заслуга всей команды, что трудилась со мной тогда. Данные реальные по цифрам. Вот только не смотря на то, что и компании уже не существует, показать их в открытом доступе будет немного необдуманным решением.
Вот это вы зря. Это история из разряда реального бизнеса. Приходится работать с неидеальными инструментами и в неидеальной ситуации. Но на эту тему есть в классике (а на какую нет? :) )
You have to make the good out of the bad because that is all you have got to make it out of. (С) All the King's Men.
Верно подмечено :)
Примерно по тому же пути шел, только сфера другая и стек, а общий подход тот же.
И спал урывками, так как над проектом на тот момент работал один и кроме меня никто исправить ничего не смог бы.Все же незаменимым быть плохо.
В продолжении статьи очень хотелось бы прочитать, в кого маленькая программа превратила маленького человека из мира IT, то есть автора.
Ну так пару кликов в гугле и оп www.upwork.com/o/profiles/users/_~01495906cc55b050dc
16.25 в час.
16.25 в час.
В продолжении статьи очень хотелось бы прочитать, в кого маленькая программа превратила маленького человека из мира IT, то есть автора
Кульминация и развязка истории, надеюсь, получится куда более неожиданной, чем просто название компании.
Статья кончилась весьма внезапно. Выглядит интересно, но хотелось бы всё же хоть какие-нибудь технические подробности об архитектуре этой системы, какие были проблемы и прочее.
Это всё в следующих сериях?
Это всё в следующих сериях?
Автор хорошо поработал и у автора всё получилось, молодец автор. Спасибо что поделился.
На тот момент я не понимал, как устроен этот рынок и его нюансы, но тем не менее очевидными для меня были две вещи. Call центр необходимо строить на базе программной АТС asterisk с открытым исходных кодом.
Не очевидно. Поясните.
Не очевидно. Поясните.
Про freeswitch тогда не слышал. Asterisk комюнити было доступнее. Возможно ошибусь, но до зари расцвета облачных АТС (которые в большинстве своем на том-же asterisk реализованы)
Это было единственное доступное для разработчиков открытое решение. Хотя и тогда найти нормального специалиста было, ну, далеко не просто. Другие решения не рассматривал. Нужна была программная АТС, которую можно масштабировать под «свои уникальные» задачи :)
Из стихотворения «Мне ни к чему одические рати...» (1940) Анны Андреевны Ахматовой (1889—1966):
Когда б вы знали, из какого сора
Растут стихи, не ведая стыда.
Как желтый одуванчик у забора,
Как лопухи и лебеда.
Сердитый окрик, дегтя запах свежий,
Таинственная плесень на стене…
И стих уже звучит, задорен, нежен.
На радость всем и мне.
По моему мнению любой удачный коммерчески проект вырастает из ужасного сляпанного
на коленке прототипа. А академически правильные остаются предметом докладов на конференциях.
Когда б вы знали, из какого сора
Растут стихи, не ведая стыда.
Как желтый одуванчик у забора,
Как лопухи и лебеда.
Сердитый окрик, дегтя запах свежий,
Таинственная плесень на стене…
И стих уже звучит, задорен, нежен.
На радость всем и мне.
По моему мнению любой удачный коммерчески проект вырастает из ужасного сляпанного
на коленке прототипа. А академически правильные остаются предметом докладов на конференциях.
Как-то слишком мало подробностей. Я сам занимался похожим проектом, и подводных камней было весьма немало:
— плохая связь. Как это отследить? Как корректно восстановить состояние?
— каким водителям отослать новый заказ? Как выбрать водителя или водителей, кому отослать новый заказ в первую очередь*
— одновременный прием одного и того же заказа несколькими водителями. Как корректно обработать на сервере, чтобы не было логических гонок? Как корректно обработать это на клиенте в условиях нестабильной связи?
— прием координат от водителей. Как корректно строить траекторию с учетом того, что координаты сильно зашумлены, могут не приходить из-за проблем со связью, или водитель заехал в туннель, а могут «телепортироваться» вообще на другой конец города?
— прием событий от сервера клиентом. Как лучше реализовать — периодический запрос событий клиентом, или отсылку сервером по своей инициативе? Как быть, если связь оборвалась, и событие не дошло. Когда перепосылать? Как сделать, чтобы из-за перепосылок клиенту не пришло одно и то же событие несколько раз?
— построение маршрутов. Как и когда их строить, чтобы при этом не разориться на запросах к гуглу или яндексу? Что из этого можно закэшировать?
и так далее. И тут уже не важно, будет ли сервер под windows или использован другой стек…
— плохая связь. Как это отследить? Как корректно восстановить состояние?
— каким водителям отослать новый заказ? Как выбрать водителя или водителей, кому отослать новый заказ в первую очередь*
— одновременный прием одного и того же заказа несколькими водителями. Как корректно обработать на сервере, чтобы не было логических гонок? Как корректно обработать это на клиенте в условиях нестабильной связи?
— прием координат от водителей. Как корректно строить траекторию с учетом того, что координаты сильно зашумлены, могут не приходить из-за проблем со связью, или водитель заехал в туннель, а могут «телепортироваться» вообще на другой конец города?
— прием событий от сервера клиентом. Как лучше реализовать — периодический запрос событий клиентом, или отсылку сервером по своей инициативе? Как быть, если связь оборвалась, и событие не дошло. Когда перепосылать? Как сделать, чтобы из-за перепосылок клиенту не пришло одно и то же событие несколько раз?
— построение маршрутов. Как и когда их строить, чтобы при этом не разориться на запросах к гуглу или яндексу? Что из этого можно закэшировать?
и так далее. И тут уже не важно, будет ли сервер под windows или использован другой стек…
Самый животрепещущий вопрос, для меня, вам заплатили за работу?
Столько сколько вы хотели?
Читать это как радостную историю или трагичную?
Столько сколько вы хотели?
Читать это как радостную историю или трагичную?
Самый животрепещущий вопрос, для меня, вам заплатили за работу?
Столько сколько вы хотели?
Читать это как радостную историю или трагичную?
Ну, вообще история скорее драма. Не про одного конкретного человека.
За работу заплатили. Машину подарили. Надо было просить больше сразу.
Но все-же это история не про меня…
«Прибыль 100+ млн.руб/месяц». В такси. Странно, что еще никто не засмеялся.
если с заказа брать хотя бы 50 руб.
то нужно 2*10^6 заказов
считаем 10 заказов на водителя в смену. 20 дней в месяц.
получаем 10 000 таксистов в системе.
Вполне реальная цифра для федеральной сети.
то нужно 2*10^6 заказов
считаем 10 заказов на водителя в смену. 20 дней в месяц.
получаем 10 000 таксистов в системе.
Вполне реальная цифра для федеральной сети.
Чем прибыль от выручки отличается, знаете?
1. Расчет условный.
2. Это агрегатор. Он просто берет свою долю за заказ.
3. Расходы при автоматизации на один заказ быстро снижаются.
Условно прораммистам и за сервера нужно платить в месяц 500тыс. Обслужили
1 млн заказов. 50р — 0.50
4. Агрегатор забирает себе в среднем 30% от стоимости поездки
5. Средная стоимость поездки выше 240 рублей.
Ну или все можно пересчитывать гораздо точнее. А для оценки порядка достаточно и
грубого расчета.
А вот, немного статистики про яндекс такси. Если у них доля хотя бы в четверь, то таксистов смело можно увеличить до 100-200 тысяч.
taxi.yandex.ru/blog/billion-trips
2. Это агрегатор. Он просто берет свою долю за заказ.
3. Расходы при автоматизации на один заказ быстро снижаются.
Условно прораммистам и за сервера нужно платить в месяц 500тыс. Обслужили
1 млн заказов. 50р — 0.50
4. Агрегатор забирает себе в среднем 30% от стоимости поездки
5. Средная стоимость поездки выше 240 рублей.
Ну или все можно пересчитывать гораздо точнее. А для оценки порядка достаточно и
грубого расчета.
А вот, немного статистики про яндекс такси. Если у них доля хотя бы в четверь, то таксистов смело можно увеличить до 100-200 тысяч.
taxi.yandex.ru/blog/billion-trips
Ну то есть, по Вашему, у агрегатора почти никаких затрат нет. Ни лицензий, ни аренды помещений под те же сервера, ни рекламы, ни зарплат персоналу и т.д. и т.п. Не забудьте еще, что с каждым водителем нужно оформить договор, провести расчеты, организовать прием платежей и т.д. Налоги я в счет не беру, будем считать, что это валовая прибыль.
все остальные числа в расчете можно увеличивать.
Современный таксист 6-8 часов пашет на агрегатора и автопарк у которого взял
в аренду автомобиль. И в оставшиеся 3-4 часа на себя.
Т.е. вместо 10 поездок можно заложить 20-25 (10 часов / и средняя продолжительность в 30 минут)
по данным википедии
На конец 2018 года в Москве работает порядка 100 тыс. таксистов, которые получили разрешение в Москве и Московской области
Сколько по России быстро не нашел.
Хоть это не приветствуется, но в основном у таксиста запущены приложения 2х агрегаторов.
www.audit-it.ru/buh_otchet/7704340310_ooo-yandeks-taksi
когда числа будете смотреть НЕ ЗАБЫВАЙТЕ что все в ТЫСЯЧАХ
Современный таксист 6-8 часов пашет на агрегатора и автопарк у которого взял
в аренду автомобиль. И в оставшиеся 3-4 часа на себя.
Т.е. вместо 10 поездок можно заложить 20-25 (10 часов / и средняя продолжительность в 30 минут)
по данным википедии
На конец 2018 года в Москве работает порядка 100 тыс. таксистов, которые получили разрешение в Москве и Московской области
Сколько по России быстро не нашел.
Хоть это не приветствуется, но в основном у таксиста запущены приложения 2х агрегаторов.
www.audit-it.ru/buh_otchet/7704340310_ooo-yandeks-taksi
когда числа будете смотреть НЕ ЗАБЫВАЙТЕ что все в ТЫСЯЧАХ
«Прибыль 100+ млн.руб/месяц». В такси. Странно, что еще никто не засмеялся.
Достаточно ознакомится с налоговой отчетностью Uber (где указана его текущая доля yandex) и улыбка может пропасть.
Почему именно налоговой отчетностью Uber, а не Yandex.Taxi пусть между строк читается.
Интересно было бы еще послушать, какой процент от этих прибылей достался автору… :)
Что интересно, продвинутый голосовой интерфейс вызова такси был уже тогда, в далёком 2008 году. А у известных сегодня лидеров рынка такой фичи до сих пор нет :)
Стоит уточнить, что в бесплатной редакции SQL Server 2005 допустимый размер базы не 2 ГБ (как написано в статье), а 4 ГБ, а во всех более новых версиях SQL Server'а — ограничение на размер базы 10 ГБ. При этом можно создавать несколько баз внутри одного сервера без ограничений по их количеству, а также не учитывается объем данных, хранимый по технологии FILESTREAM (это когда в базе объявлено поле с типом BLOB, а данные этого поля хранятся не внутри mdf/ndf файлов базы, а валяются рядом с базой в виде кучи мелких файлов, при этом целостность транзакций соблюдается, т.е. этими файлами SQL Server управляет целиком сам, а работа с данными по-прежнему идет через SQL-запросы).
Стоит уточнить, что в бесплатной редакции SQL Server 2005 допустимый размер базы не 2 ГБ (как написано в статье), а 4 ГБ, а во всех более новых версиях SQL Server'а — ограничение на размер базы 10 ГБ. При этом можно создавать несколько баз внутри одного сервера без ограничений по их количеству, а также не учитывается объем данных, хранимый по технологии FILESTREAM (это когда в базе объявлено поле с типом BLOB, а данные этого поля хранятся не внутри mdf/ndf файлов базы, а валяются рядом с базой в виде кучи мелких файлов, при этом целостность транзакций соблюдается, т.е. этими файлами SQL Server управляет целиком сам, а работа с данными по-прежнему идет через SQL-запросы).
Поправил, спасибо. Много воды утекло. Почему-то цифра в 2Гб ограничения в памяти засела.
«Во-вторых, было много слепых зон, где интернет просто не работал. Эту проблему мы выявили почти сразу и в течении суток устранил и обновил все установленные ранее приложения.»
«Ох уж эти сказки, ох уж эти сказочники» (с)
«Ох уж эти сказки, ох уж эти сказочники» (с)
Я так понимаю для связи с водителем Астериск не задействовался.
Он просто заедйствовался для логирования времени звонка и номера и создания заказа по Айди звонка. Вряд ли вы делали горячий и холодный трансфер, конференции тож вряд ли создавали.
Он просто заедйствовался для логирования времени звонка и номера и создания заказа по Айди звонка. Вряд ли вы делали горячий и холодный трансфер, конференции тож вряд ли создавали.
Продолжение следует..
Автор, где продолжение?)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как маленькая программа превратила маленькую контору в федеральную компанию с прибылью 100+ млн.руб/месяц