Не знаю, похвалить ли вас за то, что своим умом дошли до циклического сдвига влево методом проб и ошибок. Или похаять за необоснованные претензии к java )))
Ваш псевдокод можно написать как:
byte[] data = Files.readAllBytes(Path.of("data.pak"));
for (int i = 0; i < data.length; i++) {
byte src = data[i];
data[i] = (byte) ((src << 1) | ((src >> 7) & 1));
}
Files.write(Path.of("data_dec.pak"), data);
Некоторые пункты, приведенные как фичи котлина, уже реализованы в современных версиях java. Некоторые пункты, приведенные как плюсы, выглядят сомнительными, а местами это вовсе вкусовщина.
Называть подобный код более читаемым и поддерживаемым очень спорно. Более того, почему-то здесь не упомянуто про неочевидный return из лямбд, который в отличие от java делает возврат из окружающей функции. А чтобы выйти из лямбды придется вбивать возврат с меткой return@label. И такой код они называют читаемым, спорно, но поверим.
Другой момент с null-safe. При работе с БД у вас многие поля будут nullable. И тогда привет огород из элвисов: ?. ?. ?. Может и нечастый кейс, но точно нередкий.
Самая важное в этом всем. Котлин завязан на инфру java, но при этом развивается своим путем и добавляет свои фичи. И чтобы профессионально использовать среду вам придется хорошо разбираться и в java и в котлине.
Два пользователя изменили в оффлайне одно и то же поле одного и того же объекта
Для разрешения ситуации с потерянным обновлением надо применять родные средства http – условные запросы. Ответ на запрос состояния объекта перед редактированием возвращает вам Etag. А в запрос редактирования вы передается условие If-Match.
Автор в статье указал пример с публикацией нового ресурса через POST. По спецификации метод POST не обязан быть идемпотентным. Но вполне логично предположить, что вряд ли при случайном повторном запросе (от браузера / api-gateway или какого промежуточного прокси) вы захотите, чтобы создавался дубль объекта. Для обхода этой ситуации автор предлагает на клиенте генерировать некий ИД, по которому на сервере мы будем определять - приходил ли уже такой запрос или нет. Если приходил, то повторно ничего создавать не надо.
Через явную рекурсию не надо. Я употребил термин "рекурсия" в смысле самого подхода: что диапазон поиска сужается до того момента пока не найдем. Явная рекурсия лишь ухудшит "производительность", а ведь смысл бинарного поиска - улучшить время поиска.
Пишите новые статьи, не жалейте материала. Хоть материал и изъезженный, но сам стиль изложения тоже многое значит. Джунам будет полезно. Можно также акцентировать внимание и на особенностях javascript, чтобы любители не втыкали везде деструктуризацию, где не надо )))
Первый элемент я бы получал через деструктуризацию const [start, …rest] = arr;
Вы серьезно предлагаете порождать ненужные объекты там, где легко можно обойтись без?
Более того, скорее всего вы не поняли сам алгоритм бинарного поиска, раз предлагаете таким образом читать значения массива. Единственный "читаемый" элемент массива - это текущая середина (arr[middle]), с ним мы сравниваем и рекурсивно сужаем локацию поиска до нужной части.
Не знаю, похвалить ли вас за то, что своим умом дошли до циклического сдвига влево методом проб и ошибок. Или похаять за необоснованные претензии к java )))
Ваш псевдокод можно написать как:
Некоторые пункты, приведенные как фичи котлина, уже реализованы в современных версиях java. Некоторые пункты, приведенные как плюсы, выглядят сомнительными, а местами это вовсе вкусовщина.
Называть подобный код более читаемым и поддерживаемым очень спорно. Более того, почему-то здесь не упомянуто про неочевидный return из лямбд, который в отличие от java делает возврат из окружающей функции. А чтобы выйти из лямбды придется вбивать возврат с меткой return@label. И такой код они называют читаемым, спорно, но поверим.
Другой момент с null-safe. При работе с БД у вас многие поля будут nullable. И тогда привет огород из элвисов: ?. ?. ?. Может и нечастый кейс, но точно нередкий.
Самая важное в этом всем. Котлин завязан на инфру java, но при этом развивается своим путем и добавляет свои фичи. И чтобы профессионально использовать среду вам придется хорошо разбираться и в java и в котлине.
Предлагаете другому потерять исправление опечатки?
Это уже вопрос совместного доступа и резолва конфликтов. Это проблема уровня приложения, а не транспорта. Транспорт вам тут никак не поможет.
Для разрешения ситуации с потерянным обновлением надо применять родные средства http – условные запросы. Ответ на запрос состояния объекта перед редактированием возвращает вам Etag. А в запрос редактирования вы передается условие If-Match.
Автор в статье указал пример с публикацией нового ресурса через POST. По спецификации метод POST не обязан быть идемпотентным. Но вполне логично предположить, что вряд ли при случайном повторном запросе (от браузера / api-gateway или какого промежуточного прокси) вы захотите, чтобы создавался дубль объекта. Для обхода этой ситуации автор предлагает на клиенте генерировать некий ИД, по которому на сервере мы будем определять - приходил ли уже такой запрос или нет. Если приходил, то повторно ничего создавать не надо.
Через явную рекурсию не надо. Я употребил термин "рекурсия" в смысле самого подхода: что диапазон поиска сужается до того момента пока не найдем. Явная рекурсия лишь ухудшит "производительность", а ведь смысл бинарного поиска - улучшить время поиска.
Пишите новые статьи, не жалейте материала. Хоть материал и изъезженный, но сам стиль изложения тоже многое значит. Джунам будет полезно. Можно также акцентировать внимание и на особенностях javascript, чтобы любители не втыкали везде деструктуризацию, где не надо )))
Вы серьезно предлагаете порождать ненужные объекты там, где легко можно обойтись без?
Более того, скорее всего вы не поняли сам алгоритм бинарного поиска, раз предлагаете таким образом читать значения массива. Единственный "читаемый" элемент массива - это текущая середина (arr[middle]), с ним мы сравниваем и рекурсивно сужаем локацию поиска до нужной части.