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

Тем не менее, иногда даже в такой консервативной сфере случаются серьёзные прорывы и, одному из них, многие из нас, были свидетелями: на рубеже между 1980 и 1990 годами благодаря открытию и широкому внедрению редкоземельных магнитов  NdFeB (неодим-железо-бор) , SmCo (самарий-кобальт) произошла тихая революция в электродвигателях, где, благодаря таким магнитам удалось кардинально улучшить их характеристики: в те годы даже ходила поговорка, что «электродвигатель никогда не будет летать», из-за большого веса старого типа двигателей (особенно это поговорка касалась малой, беспилотной авиации), а повсюду властвовали исключительно двигатели внутреннего сгорания. 

И вот, нынешнее поколение уже даже, наверное, и не представляет, что «а разве когда-то было иначе?», видя, как лавинообразно распространяется беспилотная авиация, дроны. 

В свете всего этого, имеет смысл ещё раз взглянуть на историю электродвигателей, как таковых…

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

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

Я берусь доказать, что основной тезис ошибочен. В РФ нет дефицита кадров. 

Что нужно знать

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

Оригинал

В 2003 году Алан Кей, признанный автор термина «объектно-ориентированное программирование», ответил на вопросы исследователя Штефана Рама. В этом письме он раскрывает первоначальный замысел ООП, который значительно отличается от того, чему большинство из нас учат сегодня. Публикуем перевод этого исторического документа.

Помните, одно время тематические площадки заполонили статьи вида: «Я устал от [плохих] приложений для изучения английского, поэтому сделал своё» или «Я устал от [неправильных] трекеров продуктивности, поэтому создал собственный»? В реалиях современных аппсторов заголовок можно сократить до: «Я устал».

Статистика говорит, что app fatigue is real. А мы в Beeline Cloud решили посмотреть, как менялось отношение к приложениям — от «эры пост-ПК» до настоящего времени.

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

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

Ведь дьявол кроется в деталях.

Я наткнулся на эту статью, когда проходил практику в IBM Almaden Research Center. Женщина, сдававшая мне комнату в Сан‑Хозе, в прошлом сотрудница IBM, время от времени получала небольшую бумажную газету под названием «Think twice!». Я даже не уверен, какой у неё был тираж. Сто экземпляров? Двести? Но статья настолько мне понравилась, что я не поленился и вручную перепечатал её. 20 лет я прятал этот текст в самых тайных папках, перенося с одного компьютера на другой (как те золотые часы, которые носили в своих задних проходах герои фильма «Криминальное чтиво»), и сегодня решился наконец выложить его перевод на всеобщее обозрение. Если верить гуглу, то я — единственный в мире обладатель этого текста.

Желаю приятного прочтения.

Подумай дважды!

Попробуйте поискать в Интернете «Паттерны проектирования на Python» — и получите целую простыню туториалов, демонстрирующих, как в точности воспроизвести на Python паттерны проектирования из книги «Банды четырёх». Там же будут диаграммы классов, иерархии фабрик и столько шаблонного кода, что выхлопа хватит, чтобы отопить маленькую деревню. Так вам внушают, будто вы пишете «серьёзный» код. Умно. Профессионал ьно. Готово для корпоративного использования.

Но вот в чём проблема: большинство из этих паттернов решают проблемы, которые в Python просто отсутствуют. Паттерны разрабатывались для таких языков как Java и C++, где для выполнения самых базовых вещей требуется настоящая эквилибристика — нет ни функций первого класса, ни динамической типизации, ни модулей в качестве пространств имён. Разумеется, вам потребуется Фабрика или Синглтон, если без них в вашем языке просто не с чем работать.

Слепо копировать эти паттерны в Python — не признак большого ума. Из-за них ваш код сложнее читать, тестировать, а также объяснять очередному бедняге, которому этот код придётся поддерживать. Возможно, через три месяца этим беднягой станете вы..

С тех пор, как «банда четырёх» ещё в 90-е выпустила свою легендарную книгу «Паттерны объектно-ориентированного проектирования», сами «паттерны проектирования» стали краеугольным камнем всевозможных рассуждений о программной архитектуре. Однако, со временем этот термин становится всё более размытым. Сегодня при упоминании паттернов может иметься в виду:

Назначение этого паттерна: та проблема, для решения которой он предназначен Реализация: точная структура класса или код для воплощения этого паттерна

Рассказывая о «паттернах проектирования в Python, о которых следует забыть», мы имеем в виду как раз реализации. В самом деле, эти паттерны решают реальные задачи. Но в Python решение этих задач ничуть не напоминает те варианты, которые предлагаются на C++ или Java.

Держа в уме эту идею, делаем простой вывод:

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

И почему они стоят так дёшево?

Многие в курсе, что Xiaomi, Honor, Tecno или Realme не делают телефоны сами. Но что если я скажу, что они их даже не разрабатывают? Многие бюджетные модели лишь продаются под этими шильдиками, а всю разработку и производство “от и до” делают совсем другие компании. Эти компании не на слуху, но без них не было бы никакого “топа за свои деньги”. Давайте разбираться, что всё это значит, и как так вышло.

Сегодня я и моя командой заняли первое место на хакатоне гражданских проектов. Сделали бота, ищущего контракты на капремонт по адресу, и выкачивалку-парсилку Госзакупок для него. Можно использовать как референс или брать готовый код в свои проекты, он в Public Domain: https://github.com/unxed/crwatch

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

Любой программист микроконтроллеров, Imho, рано или поздно (сейчас, скорее, рано) от одного из коллег или из статьи в интернете слышит загадочное ПЛИС или FPGA, CPLD, ПВМ — что-то такое. Если честно, то я услышал вот это загадочное, занырнул чуть-чуть, и теперь думаю, что мой опыт пригодится кому-то ещё. Если совсем честно, то статья ещё планируется как небольшая (всего в трёх частях) заметка для себя. Я когда погружался, делал пометки в текстовом файле, здесь получится их хорошо отредактированная версия.

Очень много вещей в подобных этому туториалах, которые я читал, пропускаются как сами собой разумеющиеся. Подробные инструкции куда и как тыкать есть в документации к плате разработки. Но там не хватает ответов на вопросы зачем и почему. Здесь я хочу скомбинировать 2 подхода.

Если вы управляете достаточно крупным бизнесом, вы неизбежно будете собирать аналитические данные. Вы же хотите точно понимать, почему меняются показатели продаж или какие товары будут пользоваться спросом в следующем месяце.

Звучит логично и понятно, пока вы не начнете плотно работать с цифрами и графиками. И тут, как и почти в любой сфере, кто-то рано или поздно должен был внедрить AI-ассистента. Под катом посмотрим, что из этого получилось.

Содержание