Орхан Гасанлы

Список некоторых недостатков Яндекс Маршрутизации, с которыми пришлось столкнуться:

• Одним из больших недостатков Яндекс Маршрутизации то что сервис полностью завязан на Яндекс Навигацию, в следствие чего затруднительно и порой невозможно использовать мобильное приложение курьерами при отсутствии или слабом подключения к Интернет, тут конечно же сервисы с мобильными приложениями на оффлайн картах существенно выигрывают;
  
• Нет возможности использовать другие картографические приложения;
  
• Есть сложности использования в Беларуси и Украине, хотя наверное, это больше стратегия;
  
• Цены пользования Яндекс Маршрутизации не самые гуманные и очень для многих неокупаемые;
  
• Интерфейс Яндекс Маршрутизации пока еще не отработан, логика работы кабинета логиста не очевидна и требует долгого изучения, сложный интерфейс, интуитивно непонятная логика, требуется много времени для изучения функционала;
  
• Маленький тестовый период за который не все могут разобраться с работой сервиса и принять правильное решение о его нужности бизнесу;
  
• Грузовой контур реализован только по Москве. Других городов пока нет;
  
• Нет возможности построить маршрут по собственным координатам, например, для негабаритного груза;
  
• Прогноз Яндекс Маршрутизации актуален только при трафике до 5-ти баллов;
  
• Проблемы в заполнении XLS файлов загрузки маршрутов. Для правильного заполнения требуется совместная работа логистов, программистов, менеджеров, что усложняет процесс внедрения;
  
• Нет никакой возможности редактирования и удаления данных курьеров, транспортных средств, автомобилей и т.д., в итоге накапливается мусор;
  
• Нет редактирования заказов, для изменения любых данных требуется добавление с нуля и дополнительные манипуляции, что занимает огромное количество времени логиста. Например, для изменения/добавления телефон клиента, комментария к заказу, времени или любой другой информации, требуется перезагрузка полностью всех данных;
  
• Невозможность оперативного мгновенного изменения маршрутов, отмены и изменения заказов, добавление и удаления точек маршрута;
  
• Невозможность контролировать изменения в процессе доставки;
  
• Адреса должны быть понятны Яндекс Картам, нет удобного добавления адресов по карте, что занимает много времени работы логиста.
  
• Стоимость Яндекс Маршрутизации выше чем некоторые аналоги
  

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

<a href="Controller?command=addtocart&name=${row.name}&price=${row.price}&time=${row.time}" class="button">Add to cart</a>

Где

&name=${row.name}&price=${row.price}&time=${row.time}

И есть параметры, которые будут переданы в сервлет.

Переменные в сервисах мало чем отличаются от глобальных переменных. По сути - это и есть глобальные переменные со всеми вытекающими последствиями. Например, переменная сервиса может быть неожиданно изменена во время какого-нибудь асинхронного действия. Что приведёт к неожиданным/нежелательным сайд-эффектам. Современные ООП парадигмы (например, ДДД), напрямую говорят о том что сервисы не должны хранить состояние.

Это приведение типа. Прямо так и гугли.

Matcher умеет сам генерировать стрим:

// Java9+        
        var integers = Pattern.compile("-?\\d+").matcher(source)
                .results()  // Stream<MatchResult>
                .map(MatchResult::group) // Stream<String>
                .map(Integer::valueOf)
                .toArray(Integer[]::new);

// Java8
        Integer[] integersJ8 = Pattern.compile(",")
                .splitAsStream(source)
                .map(String::trim)
                .map(Integer::valueOf)
                .toArray(Integer[]::new);

https://ru.wikipedia.org/wiki/%D0%94%D0%BE%D0%BF%D...
В частности, для byte это означает, что числа принимают значения от -128 до 127, а не от 0 до 255 как это могло бы показаться.
То же самое и для знакового целого int

Потому что условия проверяются слева направо.

Поэтому ставить проверку customArray на null второй нет никакого смысла - если массив не null, то до нее дело не дойдет; если же он null, то выполнение свалится с NPE.

А вот поменять их местами смысл как раз имеет - первым мы проверяем, не null ли customArray, и только если нет, тогда обращаемся к объекту, запрашивая его размер.

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

Он возвращает значение в то место, где был вызван метод.
Тоесть как-то так (псевдокод)

void main() {
  var x = getSomething();
  // x == 42
}

int getSomething() {
  return 42;
}

<a href="<?php echo esc_url( home_url( '/' ) ); ?>"><img src="<?php echo get_template_directory_uri(); ?>/assets/img/logo.png" alt=""></a>

String regex = "^\\d+([,.])\\h*\\d+(\\1\\h*\\d+)*$";

https://regex101.com/r/c4RYTj/1

Нужно сделать так:

const onFocus = (event: React.FocusEvent<HTMLDivElement>) => {
    event.currentTarget.classList.add("ticket--focus")
  }

  const onBlur = (event: React.FocusEvent<HTMLDivElement>) => {
    event.currentTarget.classList.remove("ticket--focus")
  }