Alexey Hog

marker.geometry.setCoordinates

function merge(...$arrays) {
  $result = [];

  foreach ($arrays as $arr) {
    foreach ($arr as $key => $values) {
      if (!isset($result[$key])) {
        $result[$key] = [];
      }

      for ($i = 0; $i < count($values); $i++) {
        $result[$key][$i] = ($result[$key][$i] ?? 0) + $values[$i];
      }
    }
  }

  return $result;
}


$arr = merge($arr1, $arr2);

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

select * from
(select r.id as reader_id, r.first_name, r.last_name, b.id book_id, b.name, b.pub_date, row_number() over (partition by r.id order by l.taken_at desc) as rownum
from readers r
left join log_taking l on r.id = l.reader_id
left join books b on b.id = l.book_id
) a
where a.rownum = 1

PS: Связка left join выведет всех читателей, в независимости, брали они книги или нет. Просто join даст список читателей, которые брали книги хоть один раз.
PPS: Оконные функции доступны с MySQL версии 8.
Если версия 5, то придется городить велосипед с пользовательскими переменными.

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

"Как убрать" - очевидно, вызывать join самостоятельно, указывая пустую строку.

SVG + 2 маски, одна пропорционально растягивается, другая непропорционально. Отрицательным margin загнать секции одна на другую.

функция возвращает пустой объект, если круглые скобки убрать то получится пустой блок кода, а не объект.
() => ({}) равнозначно () => {return {}}

Как будем определять, должен ли элемент остаться: const mustStay = n => n !== null;.

Собираем новый массив:

const newArr = arr.map(n => ({
  ...n,
  array2: n.array2.filter(mustStay),
}));

Обновляем существующий:

arr.forEach(n => n.array2.reduceRight((_, n, i, a) => mustStay(n) || a.splice(i, 1), 0));

// или

for (let i = 0; i < arr.length; i++) {
  const a = arr[i].array2;
  a.splice(0, a.length, ...a.filter(mustStay));
}

// или

for (const { array2: a } of arr) {
  let numDeleted = 0;

  for (const [ i, n ] of a.entries()) {
    a[i - numDeleted] = n;
    numDeleted += !mustStay(n);
  }

  a.length -= numDeleted;
}

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

Поэтому все зависимости обычно передаются через конструктор (и поэтому и называются инъекция зависимостей.)

Таким образом мы можем менять поведение класса, не меняя его код

Но тут надо понимать, что всё это работает только при правильном применении ООП. А точнее просто при применении ООП. Потому что 98% "ООП" кода, который пишется на РНР - это голимая процедурщина, даже если она обёрнута в классы и методы. Если у тебя метод класса представляет из себя стену кода, которую ты тупо перенёс из файла, инклюдившегося в любимое похапешное спагетти - то это не ООП. Это та же процедурщина, вид сбоку. И смысл использования dependency injection ты с ним не почуствуешь. Будешь конечно применять, но в качестве карго культа - потому что тебе это на тостере написали.
А вот когда твой код начнет становиться действительно объектным - тогда стразу станет понятнее.

Похожим на сервис локатор является сервис- или DI-контейнер. Используемый вручную, он является тем же самым сервис локатором. Поэтому вручную его никогда не надо вызывать - что и запрещается в симфоневских конроллерах - а только для автоматического создания классов. В МВЦ у тебя ведь очень многие объекты создаются автоматом - сущности, контроллеры. И вот для того, чтобы при автоматическом создании экземпляра класса у тебя были на руках все требуемые сервисы - и нужен контейнер.

Соотвтственно, ответ на вопрос "что использовать?" очень простой:
- при ручном создании экземпляра объекта, все зависимости передавать в него через конструктор, а не получать "из воздуха" в коде.
- при автоматическом создании экземпляра объекта, использовать dependency injection container

В этим смысле очень полезно освоить Симфони - строгий фрейворк, в котором нет сервис локатора и в котором запрещено пользоваться контейнером напрямую.

Хм...вариантов так то масса
1. Купить виртуальный номер (пользоваться им как на смарфтоне (через фирменное приложение или acrobits), так и на компьютере (ПО или WebRTC).
Сделал скриншот - звоню прям из браузера

2. Если у вас есть мобильный номер, то его можно подвязать к виртуальной атс (работает только с мегафоном по sip-протоколу) и пользоваться также как в п.1.
Либо без использования виртуальной АТС - ставите ПО на комп PhonerLite или Bria Solo (X-Lite) и прописываете мегафоновские настройки sip (услуга мультифон).
3. PS: При использовании sip телефонии можно и управление голосом прикрутить (на айфон команды siri, на андроиде наверняка тоже что то есть + телеграм (который на сервер шлет команды для набора номера (обратный звонок)).

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

ЗЫ2:
Блютуз гарнитура + таймвьюер для андроид, не?

$chunks = array_chunk($arr, 2);
$newArr = array_combine(array_column($chunks, 0), array_column($chunks, 1));

или

for ($i = 0; $i < count($arr); $i += 2) {
  $newArr[$arr[$i]] = $arr[$i + 1];
}

не обязательно.
но назовите хоть одну причину делать иначе?

Прикольно звучат высказывания комментаторов в духе "если вы знакомы с проектом". Мне правда интересно, как в условиях современных монстроподобных корпоративных приложений можно быть "знакомым" с проектом, который, возможно, пилится не один год (пусть хотя бы даже от 3 лет) целой командой? Ни один человек, если он не единоличный автор этого проекта, не может быть настолько хорошо быть "знаком" с проектом, что бы чётко отвечать на вопросы в стиле "сколько времени займет поправить баг". Даже программисту среднего звена ясно, что совсем маленький баг может потянуть за собой чуть ли не фатальный коллапс архитектуры с последующим тотальным рефакторингом всего и вся.

Невозможно в разработке планировать какие-либо сроки. Тут автор прав.

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

Как оценивать сроки? Ответ очень простой - да никак не оценивать. Если работодатель построил такую систему, где менеджмент лезет с этими бюрократическими вопросами, не понимает, что разработка или фикс багов в проекте - это не типовая работа, как, например, класть кирпичи или валить лес - то это плохой работодатель. Или плохой менеджмент. А в целом - это компания-эксплуататор, из которой надо бежать.

Я по себе знаю, когда от меня требовали сроки. Последний раз был вообще трешачок в одной московской компании - от меня требовали сроки на 2 день после назначения задачи на меня, при этом я вообще не понимал ничего в задаче - в её бизнес-логике, т.к. работал в этой компании от силы недели три. Через буквально несколько дней меня вызвали "на ковер", мол, почему так долго. Жалею, что прямо тогда не послал их прямым текстом на три известные буквы, а продолжил работать. Ничего хорошего из этого, конечно же, не вышло.
Сейчас я работаю в таком месте, где ВООБЩЕ нет никакого понятия сроки, где разработка проектов в корпорации длится годами - IT работает не на внешнего заказчика, а на внутреннего - на саму же корпорацию. Последний проект, в котором я участвовал, занял около 2-х лет. И бОльшая часть была не программинг, а взаимодействие разных отделов, нахождение багов, форсмажорных ситуаций после запуска и т.д. Работать в таких условиях сплошное удовольствие. Никаких стрессов, никаких менеджеров, изображающих бурную деятельность.

Если хочешь поседеть раньше времени - оставайся и слушай упреки менеджмента. Вместо спокойной работы - придумывай эти цифры сроков. Если нет - просто ищи адекватное место работы. Другого не дано.

Я использую стандартный функционал поисковых систем из адресной строки.
Тоесть начинаю вбивать в адресной строке php.net array_diff + Enter и попадаю сразу на русскую версию документации, и на нужную страницу.
php.net можно заменить на любую другую удобную строку

Сортируем существующий массив:

messages.sort((a, b) => {
  [ a, b ] = [ a, b ].map(n => sortableLanguages.indexOf(n.language));
  return a === -1 ? 1 : b === -1 ? -1 : a - b;
});

Собираем отсортированный новый:

const sorted = (arr, key) => arr
  .map(n => [ n, key(n) ])
  .sort((a, b) => a[1] - b[1])
  .map(n => n[0]);


const order = Object.fromEntries(sortableLanguages.map((n, i) => [ n, i + 1 ]));
const sortedMessages = sorted(messages, n => order[n.language] || Number.MAX_SAFE_INTEGER);

// или

function sorted(arr, order, key) {
  const ordered = new Map(order.map(n => [ n, [] ]));
  const unordered = [];

  arr.forEach(n => (ordered.get(key(n)) || unordered).push(n));

  return [].concat(...ordered.values(), unordered);
}


const sortedMessages = sorted(messages, sortableLanguages, n => n.language);