Очередное исследование популярности языков программирования, на этот раз весьма серьёзное -- от авторитетнейшего Института инженеров электротехники и электроники IEEE, разработчика множества ИТ-стандартов.

Резюме двумя словами: доминирование Python. Второй Java, далее Си, С++ и JavaScript.

Надо конечно учитывать определённую специфику IEEE -- прежде всего инженеры-электронщики, которым нужен мощный и простой технический инструмент программирования и вычислений, и чтобы его можно было легко освоить. В некотором смысле Python сегодня -- как Basic в 1980-1990-е :-) Ну и конечно широчайшая популярность Python и в веб-разработке, и в научных вычислениях, и в машинном обучении, и как стандартный язык прикладного программирования во всех дистрибутивах Linux.

https://spectrum.ieee.org/at-work/tech-careers/top-programming-language-2020

Глубокомысленное исследование North Carolina State University и Microsoft внезапно выявило факт, о котором раньше как будто бы никто и не знал (это сарказм :).
https://news.ncsu.edu/2020/07/tech-job-interviews-anxiety/

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

И следствие отсюда по Кэпу Очевидность, что и кадровые агентства этим занимаются, и сами кандидаты это хорошо знают и практикуются, и я на курсе карьеры подчёркиваю: к успешному прохождению интервью надо готовиться целенаправленно, чётко понимая, что это совершенно отдельный набор скиллов, к прямой работе особого отношения не имеющий. Ну и вот в Microsoft этим обеспокоились, видимо поднабрали ребят, которые хорошо выступают у доски и красиво вешают лапшу на уши :-)

Есть такая классическая проблема двух генералов. Две армии окружили город с двух сторон, но у них нет связи друг с другом. Город можно захватить, только если атаковать одновременно, поодиночке каждая армия погибнет.

Можно послать посыльного, но весьма вероятно, что его перехватят, и как 1-й генерал узнает, что он доставил сообщение о времени начала атаки? 2-й генерал может отправить ответного посыльного, но как он сам узнает, что 1-й генерал получит его? А вдруг его перехватят, и 1-й генерал решит, что и первый посыльный не добрался, и отложит атаку...

Проблема эта решения не имеет. Она часто упоминается на курсах по сетям при изучении протоколов TCP/UDP.

По этой причине создание распределённых систем -- тяжёлая задачка, и достичь 100% надёжности невозможно. Едва только возникает режим взаимодействия серверов, мы обречены на вероятности. А ведь с ростом популярности модели serverless вообще абсолютно всё становится распределённым :)

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

Какими подходами этого достичь, рассмотрим далее.

Есть несколько стратегий обеспечения надёжности (их можно пересчитать на пальцах полутора рук), которые надо уметь пропорционально комбинировать в своих проектах.

1. Изоляция багов.

Помните эпический сбой интернета весной 2017-го?
Инженеры AWS ничтоже сумняшеся решили провести эксперимент на живой системе :-) А давайте отключим несколько серверов S3 и посмотрим, что получится? (серьёзно). Отлаживался балансировщик нагрузки, и как всегда что-то пошло не так -- отключилось слишком много серверов, нагрузка на остальные резко возросла, ну и они посыпались.
А так как на S3 как на хранилище файлов завязана по сути вся AWS, то поломалась и её существенная часть. А на AWS завязана половина интернета...

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

Три правила:
1. У каждой операции в системе единственная ответственность.
2. Каждая операция атомарна (и в идеале работает как транзакция с возможностью отката если что-то пошло не так).
3. Количество взаимосвязей между операциями минимизируется.

Механизм serverless например хорошо для этого подходит и поощряет такую практику.

Например, в случае AWS надо было критически важные файлы хранить в нескольких резервных режимах, потому что тогда даже дашборды AWS затупили просто потому, что их иконки хранились на S3.

Количество вакансий для программистов в США практически вернулось к исходному уровню перед пандемией, по данным Dice Tech Job Report.
https://insights.dice.com/2020/07/28/dice-tech-job-report-q2-offers-optimism-tech-industry/
Топовым хантером этим летом стал Амазон, берёт всех подряд, Java C++ ML... Интересно, что не особо отстают от него по активности крупнейшие военные подрядчики General Dynamics и Northrop Grumman.
Аж на 51% вырос спрос на Data Engineer (видимо, имеется в виду и data science, и бигдата, и классические базы данных). Техподдержка подросла на 30-35%, программисты -- на 31%, и отдельно на Java-сеньоров большой спрос, +30%.

Правила изоляции багов (продолжение темы про обеспечение надёжности).

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

Лайфках тут простой: если в комментариях, что делает функция, вы пишете "то И сё" (имеется союз И), значит её надо дробить.

9 игр для обучения программированию с околонуля
https://www.freecodecamp.org/news/best-coding-games-online-adults-learn-to-code/

Второй всероссийский учебный онлайн фестиваль по алгоритмическому программированию и искусственному интеллекту
31 августа – 4 октября 2020
https://rucode.net/

Хорошее соревнование в минимализме вакансий :)

Видимо, фуллстек хотят:
Стэк: Java, JavaScript, Go
Денег: $4500-7000
Remote
Fintech startup (Boston)
===

В принципе, совершенно адекватное предложение, ну разве что PostgreSQL немного специфична:
Backend Senior
Стэк: Java, PostgreSQL, Spring, Linux
Денег: $3000-4000
Moscow, Russia
Ищем Senior/Lead Java Developer в продуктовую компанию
===

Ну а кто помучился с поиском и никого не нашёл, начинают удалять лишние запросы:
Стэк: Java, Kotlin
Денег: $3000-4000
Remote
Revolut ищет талантливых и амбициозных разработчиков (Москва, Берлин, Лондон, Краков)

Просто Java видимо не хотят, потому что скорее всего нужны разработчики под андроид, а набегут бэкендеры,
а просто Kotlin не хотят, потому что многие мобильные разработчики хорошо на Java кодят, но с котлином ещё не подружились.

Вообще, правильный стек в вакансиях, это что-то типа
Python + SQL + Linux
или
Java + Android
или
C# + .NET Core
или
JavaScript + Node.js
==
$3000

За каждое дополнительное слово к этому накидывайте по $1000-$1500.

Илон Маск по сути пересказывает принципы продуктивного самонаучения Алана Кэя, ну и по большому счёту, советской научной школы (самое главное -- это фундамент и широта взглядов под зонтиком единой научной методологии), которую потом западные и китайские университеты скопировали, так как ранее упирались в практическую отдачу (схема финансирования через гранты к тому подталкивала).
https://entrepreneurshandbook.co/elon-musks-2-rules-for-learning-anything-faster-cf9a79fba35

1) Растите свои знания как семантическое дерево: перед тем, как взяться за прикладные листья, убедитесь, что вы понимаете основополагающие принципы, т.е. изучили ствол и крупные ветви, иначе вашим листочкам будет не за что зацепиться.

Но уникальность стратегии обучения Маска не только в этом. Многие специалисты на протяжении многих поколений хорошо осваивают базовые принципы и концепции. Более важна его способность выращивать огромные, возвышающиеся над всеми остальными, деревья интеллекта во множестве областей.

2) Вы не можете хорошо запомнить и продуктивно освоить то, что не с чем соединить.

Маск начинал с крепких корней и мощных стволов, а затем, когда его знания стали активно расти вверх, он начал скрещивать ветви и листья с ветвями и листьями других деревьев.
Маск никогда не учится наобум. Всё, что он загружает в свой мозг, он делает системно, соединяя новое с всё более и более глубоким и прочным фундаментом.

Большинство же нынеших учеников совершенно нулевые "мастера" интеллектуального садоводства, они лишь подбирают валяющийся прямо под ногами залежалый валежник, срывают прикладные ветки. Они бродят по жизни, собирая то тут то там обманчиво лакомые "прикладные" кусочки, пока не наполнят свои руки видимостью знаний.
Обычные люди поступают "естественно": собирают то, что плохо лежит, ведь в интернете валяется куча информации. Они пытаются развести из этого валежника костёр своего обучения, но он быстро прогорает, и остаётся лишь прах.

Подход Маска контринтуитивен: он не спеша сажает и сажает новые деревья в богатую почву, и они потом вырастают в густые и обильные знаниевые структуры с мощными перекрещивающимися ветвями, стабильно приносящие вкуснейшие и сочные плоды.

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

В последнее время на Javy что-то везде наезжают, каналы java memes прям плодятся, считаю, несправедливо. Да, бумеры её традиционно недолюбливают, но в основном "по старой памяти", когда были ужасающие java-апплеты в браузерах, а сама она в плане изучения была куда сложнее плюсов, ну и реально тормозила. Но сегодня, про проблемы с быстродействием можно забыть, особенно на фоне популярности питона, а когда выкатили Java 8, вообще стало норм.

Объективно, из 5-7 ведущих мэйнстримовских языков Java -- ну, топчик с т.зр. кампутер сайенса, т.к. Тьюринг-полнота её системы типов была доказана ещё лет пять назад, по моему. А вот в C# например генерики это фича, которая разрешается в рантайме (претензии, точнее, к CLR), ну и вообще type-checking шарпа is NP-hard.
А вот CSS -- ТП :) Продуктивнее всего кстати доказать, является ли система типов некоторого языка ТП -- это реализовать на ней комбинаторную логику, SKI calculus.
Ну вот, классика метапрограммирования: Scala type level encoding of the SKI calculus
https://michid.wordpress.com/2010/01/29/scala-type-level-encoding-of-the-ski-calculus/

Это я к тому, что как только возникает достаточно серьёзный проект, завязанный на формальные методы, когда верификацию, пруфы-скрипты, надо выгонять в прикладной код, вот и оказывается, что кроме Java и взять-то особо нечего. В этой вашей гошечке система типов -- днище 90-х годов; даже если динамические языки брать, то в питончике замыканий нормальных никогда не было, и т. д.

Антон работал до 30 лет продажником, а потом двинул в дата-сайнс.
1,5 года на обучение,
перепробовано 11 курсов,
потрачено 163 тысячи на освоение профессии.
Устроился в итоге в банк, вместе с премией получает 160-170т.
https://journal.tinkoff.ru/become-analytic/

А что если в ящик Шрёдингера поместить не котика, а компьютер, считающий некоторую задачу? Фактически, можно его не запускать, и тем не менее получить результат вычислений. Компьютер ждёт, пока кто-то не нажмёт "Старт", но при этом выдаст результат. С точки зрения ограниченного здравого смысла это невозможно, однако эксперименты с подобными -- так называемыми контрфактуальными вычислениями — успешно проводились физиками ещё 15 лет назад.

https://www.osp.ru/cw/2006/08/376287

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

И вот шикарный свежачок
https://fqxi.org/community/forum/topic/3345

А что, если контрфактуальные вычисления моделируют работу мозга? тогда мы получим зомби Шрёдингера, который как-то действует в мире, "мыслит", но при этом собственного опыта думания у него нету.

Тут же известная тема квантовых бомб Элицура-Вайдмана, когда есть бомбы, которые взрываются при любом факте их физического наблюдения (например, при попадании единственного фотона), однако в нашей реальности тем не менее возможно выяснить, какие конкретно бомбы рабочие, не взорвав их.
https://www.nkj.ru/archive/articles/17795/

В частности, применяя контрфактуальные вычисления, мы можем теоретически организовать жизнь так, чтобы гарантированно получать только счастливые результаты, и гарантированно избегать плохих результатов.

Просветлённые, впрочем, научились этому ещё тысячи лет назад.

=

Резюме такое, что пока сами квантовые физики по мере исследования темы офигевают всё больше и больше :)

Философия Unix (14 принципов правильного кода) применительно к Zen of Python
https://blog.finxter.com/the-unix-philosophy/

Удивительно, но я не нашёл перевода весьма сильной концепции Дядюшки Боба -- Transformation Priority Premise (TPP) аж 7-летней давности. Может в какой его книге есть?

https://blog.cleancoder.com/uncle-bob/2013/05/27/TheTransformationPriorityPremise.html

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

Дядюшка Боб ввёл трансформации в контексте его любимой TDD (разработка, управляемая тестированием), по мантре "чем более конкретны тесты, тем более общим получается код". Идея, что, применяя к коду последовательность трансформаций, мы получаем всё более и более общую (универсальную) систему.

Дядюшка Боб предложил очень красивое правило: любое изменение вашего кода должно быть либо преобразованием его поведения из специфического в более общее, либо рефакторингом.

То есть, новая схема TDD, расширяющая оригинал "красный/зелёный/рефакторинг":

упавший тест => трансформация => пройденный тест => рефакторинг => пройденный тест

Трансформации из верхней части списка более просты и менее рискованны, а главное, что они более предпочтительны. Например, лучше превратить константу в переменную, или скалярную переменную в массив, чем добавлять оператор if.

Ещё тогда Дядюшка Боб говорил, что "the sequence of tests, transformations, and refactorings may just be a formal proof of correctness."

Список трансформаций

Тренды цифровизации и в ближайшее, и в отдалённое время, таковы, что продолжит быстро автоматизироваться всё больше и больше традиционных «работ». Огромный вклад в это всё вносит пока ещё сильно недооценённое машинное обучение, и на самом деле уже и высококвалифицированные «знаниевые» специалисты – айтишники, программисты, врачи, учителя, финансовые аналитики и т. д. и т. п. находятся под совершенно реальной угрозой быть заменёнными софтом.

Мы живём в эпоху машинного обучения и data science.

И упущение скилла Data Science, не говоря уже об AI/ML, может стать самой дорогостоящей ошибкой в вашей карьере.

Независимо от того, в какой области программирования вы специализируетесь.

Помните (скорее всего, нет))), как Билл Гейтс едва не прое… всю свою Microsoft, отказываясь верить в перспективы интернета в эпоху его зарождения? И до сих пор расплачивается тем, что ни один из микрософтовских браузеров так и не взлетел, а попытки его пропихнуть насильно, когда уже появились сильные конкуренты, привели к тому, что кривейший IE возненавидели почти все, а судебное разбирательство тянулось до 2000-го года, и Microsoft была вдобавок признана виновной в монополизме.

По моей методике 1-2-4-8 (всегда есть что-то одно самое-самое важное, что надо изучить в первую очередь), чтобы войти в DS, прежде всего надо изучить библиотеку NumPy.

https://numpy.org/doc/stable/user/quickstart.html
https://habr.com/ru/post/352678/

Набор ноутбуков по NumPy (без подсказок -- с подсказками -- с решениями)
https://github.com/rougier/numpy-100

В идеале лучше сделать все 100 задачек:)

Ну, с Всемирным днём логики! :) 💥💥💥
Матлогика, формальная философия и теории типов из computer science — всё это одно.
Программист, кодирующий некоторую модель мира с помощью, например, классов ООП, по сути занимается формальным кодированием некоторого наблюдаемого феномена.
Причём этот процесс двойственный: получающаяся модель определяет как внешнее, так и внутреннее — выражает уровень, силу рационального мышления самого кодировщика.
Базовый ранг, когда разработчика действительно можно считать зародышем Программиста — когда он способен представить любую свою модель в системе типов MLTT.
Ну и он становится формальным философом-джуниором, если например научился использовать h-уровни в HoTT.

Либа Pandas -- второй из трёх must have-навыков DS, который нужен каждому датасайентисту. А на самом деле data science -- уже абсолютно обязательный скилл любого уважающего себя программиста, игнорирование которого может стоить вам всей карьеры.

Ноутбуки (есть также с решениями как и для NumPy), там же ссылочки на быстрые старты, хорошо всё прописано
https://github.com/ajcr/100-pandas-puzzles

Ещё можно посмотреть
https://github.com/guipsamora/pandas_exercises