Dimonchik

Второй цикл нужен для того, чтобы сложность алгоритма была О(n^2)
:)

Залезть в guzzle и посмотреть как у них называется обертка над curl_multi, либо использовать curl_multi. Но если их много то не надо кидать туда сразу все, если система слабая, повесишь ее намертво.

Тут есть очень простое объяснение:

1) Это Unity, которая сильно снижает планку зп по рынку.
2) Студенты. Майкрософт хорошо лоббирует .net в универах, поэтому большая часть студентов (которые готовы работать за еду), идут со знанием .net
3) В США большая часть .net работы — это компании в области гос/финтех-сектора. У нас же по историческим причинам, в этом секторе основной игрок Java. Следовательно и деньги в .net не идут.
4) .Net — дорогой стек, поэтому все стартапы, которые вынуждены большой зп конкурировать с более «стабильными» компаниями за разработчиков, выбирают python/java/php, а не .net. Хостинг на .net — крайне разорителен (сейчас, конечно, появился .net core — но он еще слишком молод, чтобы поменять ситуацию).
5) .net часто используется во всяких тендерных проектах, где руководство использует принцип «совка». Разработчик должен быть голодным и «уставшим».

___

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

Реально открываешь вакансии, там middle .net разраб — 90-120к тысяч. Хотя проекты такой же сложности на Java — идут уже 120-150к. В общем, так сложилось, что .net платят меньше, и работодатели не шибко хотят поднимать эту планку.

Ну, никто не отвечает, отвечу я.

1) Можно ли вообще публиковать свои приложения в стор из России?

А почему нет? Очень странный вопрос.

2) Можно ли публиковать платные приложения от физиков или нужно ИП, ООО?

От физиков - да, обязательно. Остальные могут так.
Шучу, конечно, в плане легализации дохода нет никаких отличий от Google Play или AppStore.

3) Как стор выводит деньги и выводит ли их в РФ. Сам перевод идет в рублях или уже в долларах?

На этом моменте мне надоело отвечать на разжёванные тысячу раз вопросы. Вот человек мечтает о Нью-Йорках, о светлом будущем, ему говорят - гугли, гугли, а он всё так и не научился. Ознакомьтесь хотя бы с первой ссылкой в выдаче:
https://habr.com/ru/company/microsoft/blog/147697/

Есть по нему движуха или это мертвая площадка и не стоит в неё инвестировать время?

Да конечно мёртвая, о чём речь. Всего-то 90% десктопов.

"Размеры" - это ширина и высота? Если да, то нужно знать формат, после чего - получить только ту часть файла, которая содержит параметры. Например, сегмент SOF0 или SOF2 в случае JPEG.

Сейчас постараюсь объяснить своими словами, а ниже прикреплю более полную и точную информацию.

0. age - приватная переменная, которая доступна только в пределах этого класса.

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

2. SetAge() - публичная функция, которая устанавливает значение приватной переменной. Называется сеттер, от слова Set.

Для чего это нужно?
В первую очередь, для безопасности, а также:
- соблюдение одного из основных принципов ООП (на котором и построен C#) - инкапсуляция.
- для того, чтобы нельзя было напрямую изменять переменную из других классов.
- для того, чтобы задавать дополнительные условия.
Например, в SetAge() можно написать условие, при котором возраст можно указать только в пределах от 0 до 100, это позволит избежать множества ошибок.

Также в C# существует более удобный синтаксис:
public int Age { get; set; }
Это если нужно просто принимать или устанавливать значение, также set или get можно вообще не писать, если он не нужен. А для более сложной логики можно написать так:

private int _age;
public int Age
{
    get
    {
        return _age;
    {
    set
    {
        if(value > 0) _age = value;
    }
}

Статья на docs.microsoft:
https://docs.microsoft.com/ru-ru/dotnet/csharp/pro...

Статья про инкапсуляцию и для чего нужны get/set:
https://metanit.com/sharp/tutorial/3.4.php

Это геттеры и сеттеры. То есть функции доступа к свойству.

Зачем? Попробую объяснить простым языком. Большие программы сложно полностью загрузить в мозг отдельного человека и представлять всю структуру целиком со всеми нюансами одновременно. Поэтому принято делить программу на части. Вынос кода в отдельную функцию - один из простых способов. В ООП к этой проблеме подходят более основательно. Класс как явление - тому пример.

Класс делит программу как минимум на 2 части - то, что внутри класса, и то, что снаружи класса. Считается как бы, что класс пишет один человек, а пользуется им другой человек. Но это может быть и один единственный человек, всё равно так проще, потому что человек сначала пишет класс, тщательно всё там кодит и тестирует, а потом напрочь ЗАБЫВАЕТ, как он устроен внутри, потому что он уже готов и им можно пользоваться. То есть человек выгружает из своей ненадежной человеческой памяти эту инфу и переходит к следующей задаче, в которой просто использует этот класс. Всё, что ему нужно помнить, это то, как пользоваться классом, а всю подноготную можно забыть до тех пор, пока не понадобится улучшить класс. И здесь снова получается удобно. Когда будем улучшать класс (это не обязательно тот же самый человек), можно не думать о том, как его используют. Главное, чтобы способ взаимодействия с классом не изменился (не сильно изменился).

В вашем примере - это просто заготовка. Дальше нужно наполнять эту заготовку функционалом. В самом простом виде геттер просто возвращает приватное свойство, а сеттер меняет его. Так нужно сделать сразу, чтобы потом не пришлось переписывать всю программу (и согласовывать с коллегами). Но даже здесь уже есть небольшое правило - нельзя передавать отрицательные значения. Условия могут быть сложнее. И вообще всё может быть сложнее. Например, вместо age можно хранить дату рождения. И функция GetAge будет каждый раз высчитывать разницу с текущей датой. По сути для внешнего использования ничего не меняется, но внутри происходит магия.

\n(\d+) заменить на , $1
То есть если идет перевод строки и число, то меняем на запятую, пробел, и то самое число

Большая тема. Сразу всё сложно объять.

Wi-fi только в крайнем случае, когда совсем-совсем не получается по кабелю.

Какие важные моменты я упустил

- Питание вы упустили. При таких расстояниях PoE может не потянуть (кучу камер), либо будет много мороки. Так что как минимум это свитчи ("повторители", но на самом деле всё-таки свитчи) c PoE-out на расстоянии не более 100 метров от камер, и сами свитчи получают полноценное (не PoE-in) питание. Ещё лучше - полноценные 12V до каждой камеры. Лучше от резервируемого (бесперебойного) источника - для ОПС такие всегда используются. Соответственно, свитчи желательно поискать с питанием 12V (таких мало, но они есть, слаботочники за такими гоняются).

Следующий момент. У вас какой климат? Если не Крым\Сочи и т.п., то зимой свитчам потребуется теплоизолированный бокс с подогревом. Ну и, независимо от климата (хотя... у вас не Гоби\Сахара\Каракум?) потребуется IP65 у этих боксов.

Использовать UTP...

- ещё холиварная тема про грозо-защиту и UTP/STP... Даже не буду про это... :) Разный опыт, разные мнения, сто раз обсуждалось везде.

Возможность масштабировать систему

- хотя бы в точках, куда будет сходиться траффик от кучи камер есть смысл ставить гигабитные свитчи.

Использовать видеорегистратор или что то типа NAS Synology

- А при чём тут NAS? Видеорегистратор железный, либо видео-сервер (обычный ПК со специальным ПО, вариантов немало, большинство платные). Тут сложный выбор, эта тема обсуждалась много где, в том числе и на Тостере, надо поиском воспользоваться. Плюс в том, что этот выбор не влияет на решение остальных вопросов, и выбор можно оттягивать до последнего момента. :)

Но... Можно сделать совсем по-другому. Есть цифровые камеры, но не ip. Другая технология - AHD. Почему? А они передают сигнал по старому доброму коаксиальному кабелю, и думаю, что на 250 метров смотут работать без проблем. Не нужно городить боксы со свитчами и подогревом.
Конечно, всем IT'шникам роднее ip-технологии. :) Но лучше понимать, какие есть альтернативные варианты, и делать осознанный выбор.

У hikvison хорошее соотношение цены и качества, плюс нормальные поставки и поддержка. Так же они нормально работают с широким спектром других систем видеонаблюдения.
Использовать регистратор, можно тех же hikvision, можно альтернативные, софтовые.
Если качество не критично, можно использовать hdtvi камеры, они дают вполне приличное качество и нормально работают на таких расстояниях.
Из недостатков такого подхода. До каждой камеры свой провод, т.е. коммутаторов не будет, отдельное кабельное хозяйство, отдельное питание, как правило в камерах отсутствуют умные функции( типа поиска по зоне движения, определение саботажа, огня, дыма и т.п. ).
Если говорить об ИП камерах, тогда регистратором обойтись будет сложно.

Для 15 камер на месяц, это будет минимум 10Тб. Учитывая, что для надежности это минимум два диска. А вам нужно будет 20Тб на 30 камер, и это минимум, 2Мбит поток. 2Мбит поток более менее для камер до FullHD( т.е. до 2МП, с натяжкой до 3МП ). По факту с камерами от 3МП и выше, поток нужен 4-6Мбит, иногда и больше.

Если взять 4Мбит на 30 камер на 30 дней. Это 4*3600*24*30*30 около 40ТБ, итого 8 дисков по 10ТБ( raid 1 ).
Для такой конфигурации вам нужно будет или 2 регистратора по 16 каналов, каждый с поддержкой 4 дисков, или 4 регистратора по 8 каналов, в каждом по 2 диска.

WIFI это не про видео наблюдение, будет очень много разных не очевидных сложностей.

1. Можно и хиквижн.
2. Регистратор.
3. Ставите уличные коммутаторы типа tfortis или osnovo, подводите к ним оптику и питание, от них по PoE питаете камеры. Т.е. у вас получаются группы типа таких: https://yadi.sk/i/WmbhKUplV7UOmw
4. Вай-Фай - зло.

При помощи Cron

Полагаю, ClickHouse.

А на чем написаны плагины для питона по вашему?