Виктор П.

time.replace(/0{4}$/, '00')

// или

time.replace(/0{4}$/, m => m.slice(-2))

// или

time.replace(/00(00)$/, '$1')

// или

time.replace(/00(?=00$)/, '')

// или

time.replace(/(?<=00)00$/, '')

// или

time.endsWith('0000') ? time.slice(0, -2) : time

Распишу основные плюсы и минусы архитектур, а финальный выбор - за вами.

Arduino / AVR
+ Очень низкий порог вхождения
+ Тонны документации и примеров, в т.ч. на русском
– Дорого
– Мощности хватает не на всё. Опрос десятка датчиков - нормально, а вот графический LCD, например, USB или камера - уже проблематично.
– Arduino IDE упрощает программирование ценой раздувания и замедления кода. Наверное, лучше сразу писать на чистом C/C++.

AVR32
+ Мощные
+ Легкий переход с архитектуры AVR (по крайней мере, так утверждает Atmel)
– Дорого
– Мало документации

STM32
+ На порядок мощнее AVR
+ Стоят столько же или даже меньше
+ Есть прекрасные отладочные платы (я про серию Discovery)
+ Вполне неплохо с документацией. Есть готовые руководства по "быстрому старту".
– Поддержка все-таки не такая широкая, как у AVR
– Архитектура сложна для начинающих. Это обратная сторона мощности, и тут нет ардуиноподобной обёртки, которая спасает от "выстрела себе в ногу".

Другие ARM Cortex M (например, LPC11xx)
+ На порядок мощнее AVR
+ Стоят столько же или даже меньше
– С документацией похуже, чем у STM32
– Как всякий ARM, сложны для начинающих

Raspberry Pi
+ Полноценный компьютер
+ Дешево за систему с такой производительностью
+ Можно поставить Linux и фигачить код на Питоне
– Чтобы использовать на все 100% и писать что-то низкоуровневое, нужно быть профи
– Доступен только как плата в сборе. Взять одно ядро и использовать в своей разработке? Забудьте.

Смотря зачем)). Я когда делаю Code Review критерии следующие:

* Безопасность:
- Каждый аргумент метода простого типа должен проверяться на тип в случае его проксирования и на граничные значения в случае обработки. Чуть что не так - бросается исключение. Если метод с кучкой аргументов на 80% состоит из поверки из аргументов - это вполне норм))
- Никаких trigger_error, только исключения.
- Исключения ДОЛЖНЫ быть человеко-понятны, всякие "Something went wrong" можно отдавать пользователю, но в лог должно попасть исключение со стектрейсом и человеко-понятным описанием, что же там пошло не так.
- Каждый аргумент (объект) метода должен быть с тайпхинтингом на этот его класс, или интерфейс.
- За eval как правило шлю на **й.
- @ допускается только в безвыходных ситуациях, например проверка json_last_error.
- Перед работой с БД - обязательная проверка данных.
- Никаких == и !=. Со swtich - единственное исключение, по ситуации.
- Если метод возвращает не только bool, а еще что-то - жесткая проверка с ===, или !== обязательна.
- Никаких условий с присваиваниями внутри. while($row = ...) - тоже идет лесом.
- Магические геттеры/сеттеры разрешаются только в безвыходных ситуациях, в остальном - запрещены.
- Конкатенации в sql - только в безвыходных ситуациях.
- Параметры в sql - ТОЛЬКО через плейсхолдеры.
- Никаких глобальных переменных.
- Даты в виде строки разрешаются только в шаблонах и в БД, в пхп коде сразу преобразуется в \DateTimeImmutable (в безвыходных ситуациях разрешено \DateTime)
- Конечно зависит от проекта, но как приавло должно быть всего две точки входа: index.php для web и console(или как-то по другому назваться) - для консоли.

* Кодстайл PSR-2 + PSR-5 как минимум, + еще куча более жестких требований (для начала все то что в PSR помечено как SHOULD - становится MUST)
- В PhpStorm ни одна строчка не должна подсвечиваться (исключением является typo ошибки, например словарик не знает какой-то из аббревиатур, принятых в вашем проекте). При этом разрешается использовать /** @noinspection *** */ для безвыходных ситуаций.
- Если кто-то говорит, что пишет в другом редакторе и у него не подсвечивается, на эти отговорки кладется ВОТ ТАКЕЕЕНЫЙ мужской половой **й и отправляется на доработку)).

* Организация кода:
- Никаких глобальных функций.
- Классы без неймспейса разрешаются только в исключительно безвыходных ситуациях.

* Тестируемость (в смысле простота тестирования) кода должна быть высокая.
- Покрытие кода обязательно для всех возможных кейсов использования каждого публичного метода с моками зависимостей.

* Принципы MVC:
- Никаких обработок пользовательского ввода в моделях, от слова совсем.
- Никаких ***ть запросов в БД из шаблонов.
- Никаких верстки/js/css/sql-ин в контроллерах.
- В моделях НИКАКОЙ МАГИИ, только приватные свойства + геттеры с сеттерами.
- В моделях разрешено использовать метод save(при наличии такого разумеется) только в исключительных ситуациях. Во всех остальных - либо insert, либо update.

* Принципы SOLD:
- Никаких божественных объектов умеющих во все.
- Если метод для внутреннего пользования - private, никаких public.
- Статические методы разрешаются только в случае безвыходности.

* Принцип DRY разрешено нарушать в случаях:
- Явного разделения обязанностей
- В тестах (каждый тест должен быть независимым, на сколько это возможно)

* Работа с БД:
- Запрос в цикле должен быть РЕАЛЬНО обоснован.
- За ORDER BY RAND() - шлю на***й.
- Поиск не по ключам (конечно если таблица НЕ на 5 строк) запрещен.
- Поиск без LIMIT (опять же если таблица НЕ на 5 строк) запрещен.
- SELECT * - запрещен.
- Денормализация БД должна быть обоснована.
- MyISAM не используется (так уж)) )
- Множественные операции обязательно в транзакции, с откатом если чо пошло не так.
- БД не должна содержать бизнес логики, только данные в целостном виде.
- Не должно быть нецелесообразного дерганья БД там, где без этого можно обойтись.

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

* О людях:
- "Я привык писать так и буду дальше" - не вопрос, ревью пройдешь только когда поменяешь свое мнение.
- "Я пишу в vim-е и мне так удобно" - здорово, код консолью я тоже в нем пишу)) но есть требования к коду, если в них не сможешь - не пройдешь ревью.
- "Я скопировал этот страшный метод и поменял 2 строчки" - это конечно замечательно, но по блейму автор всего этого метода ты, так что давай без говняшек, хорошо?
- "Оно же работает!" - вот эта фраза переводится примерно так: "да, я понимаю, что пишу полную хрень, но не могу писать нормально потому, что руки из жо", я правильно тебя понял?))
- "У меня все работает!" - рад за тебя, а как на счет продакшна?
- "Там все просто" - не используй слово "просто", от слова "совсем". Вот тебе кусок кода (первого попавшегося с сложной бизнес логикой), где там ошибка (не важно есть она, или нет)? Ты смотришь его уже 2 минуты, в чем проблема, там же все "просто"))

* Всякое:
ActiveRecord (это я вам как в прошлом фанат Yii говорю) - полное говно, примите за исходную. По факту у вас бесконтрольно по проекту гуляют модельки с подключением к БД. Не раз натыкался на то, что в тех же шаблонах вызывают save, или update (за такое надо сжигать).
То, что используется Laravel - это печально((. Что бы выполнить требования приведенные выше, приходится "воевать" с фреймворком.

Это далеко не полный список требований, очень много зависит от проекта в целом и от принципов, заложенных в нем. Для больших мредж реквестов 200 комментариев к коду - это ок. Дерзайте.

UPD

Формализировал данные критерии по ссылочке: https://github.com/index0h/php-conventions

Подсказка:

Чтобы sum(1), а также sum(1)(2) можно было вызвать новыми скобками – результатом sum должна быть функция.

Но эта функция также должна уметь превращаться в число. Для этого нужно дать ей соответствующий valueOf. А если мы хотим, чтобы и в строковом контексте она вела себя так же – то toString.

Но, если я поставлю gsm модуль и отвезу робота в поле, то у него ж не будет айпишника, я ж в таком случае не смогу сделать вебсервер, так как, по сути, это мобильник с подключением к интернету, но айпишник меняется от вышки к вышке и мобильный оператор не сможет зафиксировать выделенный белый айпишник на симку?

Почитайте про DDNS. На линуксе (Raspbian=Debian) его просто поднять.

Между малиной и дуиной можно реализовать по UART.

Нужен некий внешний сервер, который всегда будет "знать" как обратиться к вашему устройству.
На этом сервере поднимаете VPN-сервер, на вашей малинке поднимаете VPN-клиент.
Теперь не важно - то ли дома с роутера через WiFi, то ли в поле через точку доступа на вашем телефоне по WiFi - ваше устройство всегда будет видно VPN-серверу.
Ну а собственно на VPN-сервере пробрасываете порты снаружи какие надо на вашу малинку через VPN.

Самый простой вариант это использовать Parallel.Foreach.

var myEntities = new MyEntity[100];
var maxThreads = 15;

System.Threading.Tasks.Parallel.ForEach(
    myEntities,
    new System.Threading.Tasks.ParallelOptions { MaxDegreeOfParallelism = maxThreads },
    entity =>
    {
        entity.Do()
    });

Второй вариант использовать Semaphore или SemaphoreSlim.

var myEntities = new MyEntity[100];
var maxThreads = 15;	

var semaphoreSlim = new SemaphoreSlim(maxThreads);
var tasks = new List<Task>(myEntities.Length);
foreach (var entity in myEntities)
{
	tasks.Add(Task.Run(() =>
	{
		semaphoreSlim.Wait();
		try
		{
			entity.Do();
		}
		finally
		{
			semaphoreSlim.Release();	
		}
	}));
}

Task.WaitAll(tasks.ToArray());

Если вы хотите использовать класс Thread напрямую, то

var myEntities = new MyEntity[100];
var maxThreads = 3;	

var semaphore = new Semaphore(maxThreads, maxThreads);
var threads = new List<Thread>(myEntities.Length);
foreach (var entity in myEntities)
{
	var thread = new Thread(() =>
	{
		semaphore.WaitOne();
		try
		{
			entity.Do();
		}
		finally
		{
			semaphore.Release();
		}
	});
	
	threads.Add(thread);
	
	thread.Start();
}

foreach (var thread in threads)
	thread.Join();

Хотя из условий задачи кажется, что здесь вполне можно обойтись Task. Task предпочтительней еще и по той причине, что потоки переиспользуются. Т.е. задействованных потоков будет столько, сколько одновременно выполняется задач, например 15. В случае же создания потока напрямую через класс Thread, 15 будут работать, остальные просто ждать, при этом все равно расходуя ресурсы.