User
В 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-ассистента. Под катом посмотрим, что из этого получилось.
Мы все знаем, что батарея не вечна. Это нормально — можно заменить изношенную батарею в сервисе и снова использовать устройство. Но очень полезно видеть текущее состояние батареи. В MacOS это стандартная функция, в Linux мы, конечно, можем сделать то же самое. Давайте разберёмся!
Работа команды производственных айтишников на металлургическом производстве иногда тесно сплетается с командой технологической автоматизации и электрооборудования: устанавливаем датчики уровня, нужные для детального анализа технологического процесса
С точки зрения ИТ доменная печь — это огромный «чёрный ящик». Вы кладёте сырьё и топливо, получая на выходе чугун и шлак. Измерить внутри все можно почти ничего нельзя: датчики просто «умирают» от температуры, воздействия шихты и прочих условий. Измерить снаружи тоже сложно (да и нужно ли?): большие печи имеют диаметр порядка 15 метров и высоту 35 метров, — что нам дадут граничные условия для таких размеров?! По опыту на малых печах можно измерять уровень расплава (без разделения на шлак и чугун) по ЭДС внешними датчиками, но у нас так не выйдет, и нам пришлось провести целое исследование, чтобы понять, почему.
Как операционный персонал управлял процессом последние 47 лет? На базе своего производственного опыта, данных по загруженному сырью, параметров прошлых выпусков чугуна и шлака, а также косвенных параметров предполагал, как поведёт себя печь. Но управлять процессами внутри надо, поэтому остаётся только моделирование процессов по данным входа и выхода, базируясь на принципах материального баланса и используя математические ухищрения.
Если коротко, то мы те самые энтузиасты, которые «доставляют» данные, создают алгоритмы и вместе с производством добиваются эффекта. Собственно, мы оптимизируем всё что можем, и вот наконец добрались до самого нетронутого, сакрального и неизвестного легаси, вызванного «чернотой» ящика. Десятилетиями ограниченность данных воспринималась как неизбежность.
Но цифровые возможности развиваются, и мы пробуем применить самые современные цифровые решения, даже если они на грани возможного.
Публикую первую главу лекций по теории автоматического управления, после которых ваша жизнь уже никогда не будет прежней.
Лекции по курсу «Управление Техническими Системами», читает Козлов Олег Степанович на кафедре «Ядерные реакторы и энергетические установки», факультета «Энергомашиностроения» МГТУ им. Н.Э. Баумана. За что ему огромная благодарность.
Данные лекции только готовятся к публикации в виде книги, а поскольку здесь есть специалисты по ТАУ, студенты и просто интересующиеся предметом, то любая критика привествуется.
Покупаешь новый смартфон и ходишь радостный пока опять новый кастом не накатил. Он и работает шустро, и игрушки идут лучше, уж побыстрее стока. Но тут прилетело OTA, ядро новое вышло, да и Magisk обновился уже — пора ставить апдейты и получать “бутлупы”. Да, от общего числа пользователей Android смартфонов доля тех, кто сидит на кастомах крайне мала. Однако, всё же людям приходят в голову странные мысли по типу: “А не прошить бы мне свой Xiaomi, что б летал как ракета”. По такому случаю статья, в которой рассказывается про кастомные Android прошивки от А до Я.
Здравствуйте! Меня зовут Ада Ло́пес, я студентка первого курса факультета «Креативные технологии и ИИ» в Университете Хауэст в Кортрейке.
Этот проект — моя первая полностью самостоятельная работа по интеграции искусственного интеллекта с «железом». Фортепианный тренер на базе ИИ — интерактивный комплекс для помощи начинающим в обучении игре на фортепиано. Система предоставляет обратную связь в реальном времени и отслеживает исполнение заранее заданной мелодии.
Под катом — весь путь создания проекта. Мы пройдем от обучения ИИ-модели и создания корпуса — до построения контура обратной связи и решения проблем с потоковой передачей данных в реальном времени. Опыт получился отличным! Он был наполнен отладкой, открытиями и множеством ночных тестов.
Вспоминаем победы и промахи тайваньского гиганта, который недавно полностью ушел с рынка чипсетов для ПК. Для ностальгирующих очевидцев и не только.
Маркетинг при продажах крупным корпорациям это не классические продажи B2B, это целая спецоперация и пропаганда. А еще использование мягкой силы на государственном уровне. Не верите? Тогда читайте непридуманные истории.