RoflanDaniil

10800 по результатам вашего теста. Начал 3 года назад тоже с примерно 3500. Вот, на мой взгляд, лучшая методология изучения языка www.antimoon.com/how/howtolearn.htm

Немного лайфхаков:
* гуглите только на английском
* любой контент смотреть/читать/слушать только на английском. Первые 2 года будет сложно, но оно того стоит

Вот ради чего стоит напрячься:
* контент, который доходит до нас в переведенном виде - это процентов 10 от существующего контента. Знание языка даёт доступ к остальным 90%. Это очень много полезной информации. Причём в любой области. Какое бы у вас не было хобби, оно сильно обогатится, если выучить язык
* если вы программист, то автоматически зарабатываете в 2-3 раза больше соотечественников, работая на буржуев
* вам открывается доступ к американской/английской стендап комедии, она весёлая и почти не поддаётся переводу

Я думаю, если вам не нравится курс, и вы ищете способа побыстрее освоить это непростое дело (ML), то скорее всего - оно не ваше и в реальности вам не понравится им заниматься.
Дело ведь не в качестве курса и не способе подачи (видео - не видео), а в знаниях, которые вы хотите приобрести, и вопросе, зачем они вам.
Я вот, например, не люблю базы данных, но когда мне надо было быстро въехать в MongoDB и был сильный интерес в этом, то я просто прочла книгу, которая, скорее всего, в любых других условиях показалась бы мне "скучной".

> математика используется там, где могла бы не использоваться
Машинное обучение == математика. Любая модель из машоба представляет из себя оптимизируемую разными методами (чаще всего - градиентым спуском) функцию(простите за такое упрощение). Без математики максимум - это слепо тыкать модельки из интернета и тюнить гиперпараметры.

> желательно в текстовой форме ... "быстрый старт"
MNIST за 5 минут с помощью Keras.

Все зависит от настроек веб-сервера и прямоты рук администратора. Скрипт вы можете написать почти любой, но! а) не факт что он запуститься с нужными правами б) к чему есть доступ у процесса веб-сервера в древние времена я оставлял мелкую лазейку для сброса пароля к одной базе, но больше ничего сделать было нельзя, прав не хватало.

можно попробовать написать скрипт, который отправит содержимое папки(на удаленном сервере) в облако,
также можно отправить команду "top" - посмотреть процессы.

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

От просто доступа к серверу на котором нет никакой ценной инфы - нет никакого толку.
Либо же если на данном сервере крутится сайт с хорошей посещаемостью, то можно установить скрытые ссылки на свои ресурсы и т.д.

https://github.com/DrKLO/Telegram/blob/master/LICENSE

Судя по лицензии, тому кто захочет использовать (а значит изменять код под себя) придется также публиковать все в открытом доступе ибо GNU GPL

Тут аж 3 вопроса, 1 в заголовке и 2 в теле.

Зачем нужна лицензия в OpenSource проектах?

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

Каким образом может быть доказано, что я использую лицензированный код ?

Можно найти следы использования произведя реверс-инженерию. Тут всё зависит о какого типа приложении идёт речь. Если оно работает на стороне сервера, то факт использования легче скрыть.

Это значит, что любой более богатый миллиардер может запустить свой телеграм , только с другим называнием и вложить в него больше денег и заменить telegram

В теории может, на практике это так не работает. История показывает, что мало кто бросит привычный им сервис/продукт, чтобы перейти на какой-то новый, даже если последний имеет больше преимуществ. Юзеры очень консервативны, они не любят изменения и уж тем более не станут добровольно переходить с сервиса, где есть все их контакты, на сервис, где нет никого.

Поддерживают те, кому она нужна. "Майнеров" не обязательно "кормить", всё зависит от вида консенсуса и типа блокчейна. Это может быть блокчейн внутри организации (на IT-инфраструктуре организации), либо несколько нод между различными сотрудничающими организациями. Существуют коммерческие реализации блокчейна - например, IBM HyperLedger Fabric. Развернуть блокчейн можно хоть на собственном ноутбуке.

У вас один вопрос, или сотня?
При запуске программы вызывается системный вызов типа fork. При этом система дублирует адресное пространство процесса и подменяет его новым кодом, грузит библиотеки, инициализирует стек, память поцесса, открывает пути ввода/вывода. Как видите, накладных расходов куча и маленькая тележка. Операционные системы как могут, оптимизируют это дело, до какого-то предела. Поэтому все стараются избегать запуска процессов очень часто.
Что же нам теперь делать? Запустить несколько одинаковых процессов (воркеры) которые будут слушать очередь команд и выполнять нужные нам действия, а мы будем регулировать загрузку системы добавляя или убирая количество воркеров.
Так на чем же принято делать эти очереди? Можно на IPC системы, сокетах, очереди, мьютксы и семафоры. А можно на специальном ПО типа rabbitmq, zeromq, или даже на redis с его pub-sub.
Кажется на какой-то вопрос я не ответил....
А да, что выбрать? IPC или готовую очередь? Я выбираю отлаженные библиотеки!
И да, есть еще треды, они на порядок легче процессов, а есть еще сопрограммы coroutines, они легче тредов, но у всего есть плюсы и минусы.

Существует модуль позволяющий работать с разделяемой памятью https://github.com/PaquitoSoft/memored

Если хранить только в оперативной памяти (процессе ноды) - при завершении процесса все потеряется.
Если надо сохранять данные вне процесса, то есть в энергонезависимой памяти - это называется жесткий диск (самописная БД на файлах, mysql/postrgesql, redis, rabbitmq или еще что-то - не принципиально).

Обмен данными между процессами:
- быстрый, но с потерей при завершении скрипта - через сокеты.
- чуть медленнее, но надежно - через хранилище на жестком диске.

Шанс не очень велик, но есть. Посмотри, например, гитхабовский аккаунт Mourner.

Такие же как и в любом другом языке.
Шанс применить скилл ограничен проектом и ролью в проекте. Не направлением, а именно конкретным проектом, даже скорее таском. И кстати на сервере алгоритмические скиллы вот прям очень нужны могут оказаться.

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

Есть такое понятие "промышленный язык программирования". Такие языки отличает строгая типизация и наличие модификаторов доступа, обязательное указание типа возвращаемого значения функции и т.д. Короче, эти языки придуманы для "негров из трюма". Типа, вот есть несколько "офицеров в каюте", которые знают, как будет работать некий большой код в целом, и есть "негры в трюме" - они не понимают, как это будет работать, но пишут большие фрагменты всей это большой "простыни".

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

JavaScript в этом смысле - язык свободных и ответственных людей (каким ещё был, и остаётся, например, Lisp): сам наделал ошибки - сам и исправляй. Но поскольку фронт-енд стал усложняться, и в крупных корпорациях (в данном случае Google) произошло разделение на "офицеров" и "негров в трюме" - в том числе, и касательно javascript-кода, - в Гугле и придумали вариант языка JavaScript с модификаторами и типизацией, "JavaScript для негров из трюма", и назвали его TypeScript.

Вот и вся подноготная. При этом "любой код на JavaScript является кодом TypeScript" (так написано в официальной документации последнего). А что касается ООП, то оно осталось той же версией реализации парадигмы - прототипное ООП (оно и не могло стать другим - тогда это означало бы, как раз, возникновение нового языка). Но его посыпали синтаксическим сахаром, чтобы код стал напоминать синтаксис "промышленных языков" - он неграм более привычен.

Typescript он как бы на основе ES6 вырос, и побежал маленько вперёд.
А вот babel останется уделом IE11 в обозримом будущем.

Не там ищешь.