#втелеке #москва24

тот самый момент, когда твою тачку не стали снимать/заряжать по некоторым причинам, хотя изначально именно evva должна была быть звездой данного ролика :)

СМОТРЕТЬ

но как эксперта все-таки подсняли)))

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

#заряднаяинфраструктура #зарядкимосквы
#ктознаеттотпоймет

#айтишныйвзгляд

Зачем нужно свое мобильное приложение?

Мое мнение, их делают только для решения двух основных задач:
- развитие бренда
- работа с собственным клиентом

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


(тизер: и такое продается на нашем рынке))


#мобильноеприложение #whitelabel #заряднаяинфраструктура

#невсезарядкиодинаковополезны #мопеднемой

Бренд зарядки не однозначно означает качество. Проблемы случаться могут на разных. И даже очень известный бренд вне зарядок может работать в ЭЗС «специфично»

название бренда пока не буду говорить. Но понаблюдаю за ситуацией. если будет что-то интересное - расскажу

#когдазарядкананужномместе

Москва. Платная станция. В километре от Садового кольца.
Концентрация оранжевых зикров зашкаливает) А на этой станции таких одновременно может заряжаться как раз 3: один очень быстро, второй помедленнее, а третий - по переменке.

И пофигу, что не в дизайне города, зато заряжает) И даже хорошо, что платно, как мне кажется)

#зарядкимосквы #itcharge #engy

#впоискаххалявнойстоличнойчадемы

1500 до дома. А в Москве в отличие от других городов еще есть халявные ChaDeMO зарядки) и даже в ассортименте)

#зарядныйюмор #nissanleaf #зарядкимосквы

#программыдлязарядок
#почемумногоприложений

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

Оба суждения ошибочны.
Поясню.

Сложно ли сделать?
Опубликовать свое приложение не сложно. Даже красивое.
Дизайн и верстка - достаточно простые задачи. Плюс есть конструкторы, шаблоны. Осязаемо. Исполнимо. Даже недорого.
Заставить запускаться одну/две станции - тоже исполнимо. Можно взять готовые библиотеки для первичных функций протокола ocpp 1.6 в готовом виде.

До этой точки доходят многие. Отсюда и количество приложений.

Дальше уже идет реальная работа:
-разные станции (ооочень по-разному могут работать). А надо привести их к общему для работы.
-платность. Тут мало просто привязать платжку. Сначала надо данные от станции получать научиться. Гарантированно. А она не всегда их отправляет…
-доработка/дебаг/полнота реализации - часто в ПО вы можете увидеть, что доработок почти нет, хотя есть баги. Это потому что взять готовую библиотеку - легко. А вот писать элементы и механики с нуля - это другой уровень. А на костылях можно существовать, но не долго
-другие протоколы (сказать «я умею ocpp 2.0+ могу многие).

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


Но вот дальше начинаются усложнения.
-Протокол осрр 2.0 - готовых решений толком нет. Методология работы отличается. Чтобы сделать - надо реально изучить и реализовать протокол. Долго и дорого. А проверить несложно. Опытным путем. Главное, не верить на слово, так как многие, не читая и пройдя первый этап дешево, полагают, что задача быстрая.
-оплата за сессии. Ничего сложного. Прикрути платежку и будет счастье. НО. Ты должен посчитать кВт*ч. Не руками. А теперь представьте, что станция их присылает не всегда. И станция не одна. А еще бывают сессии вне авторизации (косяк станции, но онибесплатные для клиента, и поверьте, он об этом не кричит-тут только отлавливать)
-кастомизация ПО. Если отсечь дизайнерский подход: верстаем новый цвет, убираем какие-то станции от отображения и запускаем. А делать нормально: отдельный софт, с возможностью полноценной кастомизации, а не только запуск одинакового функционала на всех одновременно (так как иначе низя) с отдельными базами данными, связями, возможностью разных сервисов и т.д.
-безопасность/отказоустойчивость/масштабируемость - на этот параметр вообще пока никто внимания не обращает. Хотя уже и в РФ и в РБ было несколько случаев, когда крупные инфраструрные сети просто «лежали» даже несколько дней. И это даже не из-за атаки.

Мораль: сделать хорошо - реально. Но только если архитектура позволяет. А большое количество приложений - пофигу. Сколько бы их не плодить, все равно все сначала придет к роумингу (как только это станет задачей с коммерческими условиями), а затем к автоматической авторизации, где приложение все равно будет важно и нужно, но не всякий раз.

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

#работайтеспрофессионалами #предупреждензначитвооружен #мамкиныайтишники #tryelectro

#айтишныйвзгляд

Про ПО для управления зарядками.
Как появляются новые приложения под брендом.

Новое полноценное ПО делать дорого и сложно. Поэтому многие мобильные приложения на рынке зарядок существуют в формате SAAS (software as a service), который сводится к тому, что Разработчик делает ПО под Заказчика (в нашем случае это Мобильное приложения в формате white-label из уже готового), размещает его на серверах, публикует, поддерживает его работоспособность, безопасность и возможность развития (!).

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

Это выгодно и удобно. Но есть нюанс: Заказчик не всегда понимает нюансы. В частности, что за архитектура, насколько она пригодна для развития и масштабирования, а самое главное, где и как хранятся данные.

И вот тут начинается очень много места для возможностей различного «колхоза». Самый частый - вместо полноценного продукта в формате SAAS просто создается отдельная визуально немного отличающаяся точка входа. И все. Соотвественно, ни о каких тенантах, отдельных базах данных и возможности развивать данный сервис отдельно от основного приложения и речи не идет.

Как-то так.

Показать примеры?
Рассказать что такое тенанты и в чем преимущество?

#заряднаяинфраструктура #мамкиныайтишники #tryelectro

#айтишныйвзгляд

Как увидеть признаки костыльной/упрощенной реализации программ/приложений по SAAS невооруженным взглядом?

Безусловно, это может быть и согласованный с Заказчиком вариант, но что-то я сомневаюсь, что если спросить

«Вам важны свои клиенты или общий доступ устроит?»

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

Как увидеть?
Не сложно, особенно, если вы интересуетесь зарядками и у вам уже есть десяток- другой приложений. Итак, куда смотреть:
-смс сервис (отправитель - смотрите наименование)
-дизайн (часто плюс-минус один и тот же). Визуалику чуть поменять -не проблема. А вот механику трогать - себе дороже.
-точки на карте (повторяются. могут быть отображены частично - тут не просто фильтр)
-тарифы (идентичны.Тут же не роуминг)
-документы внутри (наименование поставщика услуг)
-наименования обновлений и версионность (очень четко видно в сторах)
-чеки

Ключевое, что смотреть (при базовой/некачественной реализации):
-ваша регистрация (данные, имя, телефон)
-ваши платежные данные (прикрепленные методы)
-история зарядок

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

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

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

#заряднаяинфраструктура #ocpp #приложениядлязарядки

Сегодня смотрел одну забавную машинку, которую локализовывают и будут запускать в такси)
Попросили не фоткать, но я уже залез сразу посмотрел, где у нее шнур разблокировки разъема (профдеформация)

Выглядит вполне симпатично.
Переднеприводной седан. Не Киа К5, конечно (мой личный топ1 в такси комфорт+), но смотрится вполне. И внутри неплоха сзади с точки зрения пассажира.

И хотя версия, которую видел я, на ццс, основная масса будет на китайском разъеме GB/t.
И цену обещают «вкусную».

Так что никуда мы не денемся от электрических такси) при чем очень скоро)

#электромобиль #такси