Это третья часть (часть 1, часть 2) из описывающих развитие процесса обучения инженеров АСУТП. Целью всех трех статей является попытка осмыслить подготовку инженеров АСУТП в ВУЗе (какая была, и какая есть сейчас), и обсудить с сообществом хабра, какой она должна быть в будущем. Каким образом ее можно актуализировать.

Год назад я закончила Bachelor's Programme in Science and Engineering по специализации ICT в Tampere University of Technology. Как это было :)

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

Всем ведь приходилось заниматься улучшением производительности? Для игр особенно актуально, ну может какая-то три-в-ряд не страдает этим. Как обычно серебряной пули нет, начинаем со структур данных, алгоритмов, спускаемся ниже если не помогает, придумываем SoA, AoS шаблоны. Если проблема не решается, подтягиваем профайлеры и предметно разбираем узкие места, но все чтобы мы не делали зачастую таким узким местом всегда будет "железо". Можно сколько угодно оптимизировать другие места, но CPU c его гигагерцами будет простаивать 90% времени если его неправильно "кормить" данными. Одной (только одной из проблем) проблемой организации эффективной работы с данными будет меньше, если знать и уметь работать с кэшами разных уровней. Тут на вики описано, как "на пальцах" быстренько убить перф на обходе массива, простого и общего решения для такого обхода нет. Можно и дальше увеличивать размер кэша, что собственно и делают (гдето здесь на хабре была новость, что Интел при переходе на L1 кэш размером 32кб, заново спроектировал блок доступа к нему, сорян не нашел ссылку), но это дорого, неэффективно на масштабах современных процов, и всегда найдутся данные, которые этот кэш отравят, опять. Интересно как починить? го под кат...

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

Определение понятия "рефлексия" из Википедии:

In computer science, reflective programming or reflection is the ability of a process to examine, introspect, and modify its own structure and behavior.

В последние годы разрабатываются варианты ввода рефлексии в стандарт C++.

В этой статье мы напишем код на C++ с рефлексией для решения разных задач, скомпилируем и запустим его на форке компилятора с рабочей реализацией рефлексии.

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

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

Всем привет. Эта третья статья про мой самодельный компьютер на логических микросхемах. Как вы догадались из названия, речь пойдет о видеокарте. Видеокарта – это, на мой вкус, лучшая часть этого проекта. Да, процессор – это интересно и круто, но всё же в нем много компромиссных решений. В видеокарте компромиссов почти нет. И рабочая частота у нее 25,175 МГц – это не жалкие 1,5 МГц у процессора.

Продолжение. К предыдущим постам и карте цикла.

Знаете, что случается, когда и архитектура вроде получилась и команда подобралась нормальная? Приходит ПОЦ. Пилотная версия. Проверка боем. Да, вы уложились в сроки и даже прошли всё внутренние проверки и тестирование на стороне клиента (UAT, SIT, PPT, ETC), так что теперь вас ждёт всё более худшее – то, что не нашли. Потому что там точно что-то спрятали. Может и не вы, но в конце точно прозвучит: «доктор, это вам!».

2.1 Комментарии обозначаются # или ''' (три одинарные кавычки)

# Комментарий
a = 1 # Комментарий 

''' Это тоже комментарий
b = c
c = d
'''

2.2 Использование динамической типизации (тип определяется автоматически)

# динамическая типизация переменных
# = копирование значения справа налево
i = 1 #  целое число (int)
f = 2.1 # число с плавающей запятой (float)
s = "a" # строковый тип (string)
b = True # логический тип (boolean)
l = [0,1,2] # массив,список (array) 
t = (0,1,2) # кортеж (tuple)
d = {"a":0, "b":1} # словарь, ассоциативный массив

print(i,f,s,b,l,t,d)
# 1 2.1 a True [0, 1, 2] (0, 1, 2) {'a': 0, 'b': 1}

# Когда хотим определить тип, используем type
print(type(i)) # Вывод <class 'int'>

# Переменная не сохраняет, а содержит фактическое значение
# Это, своего рода, переменная-ссылка, указывающая на местоположение значения
# Можно получить идентификатор актуального значения через id
print(id(l)) # 00000000000000 (меняется от исполнения к исполнениюц)
l2 = l # Приведу в пример копию массива, где ссылаюсь на 2 его элемента, а фактический массив - 1. 
print(id(l2)) # 00000000000000 (то же значение, что у вышеуказанного id(l))
# Поскольку существует только один фактический массив, кажется, что он был добавлен в массив l, даже если вы добавили элемент со ссылкой на l2.
l2.append(1)

В начале была технология и называлась она BPF. Мы посмотрели на нее в предыдущей, ветхозаветной, статье этого цикла. В 2013 году усилиями Алексея Старовойтова (Alexei Starovoitov) и Даниэля Боркмана (Daniel Borkman) была разработана и включена в ядро Linux ее усовершенствованная версия, оптимизированная под современные 64-битные машины. Эта новая технология недолгое время носила название Internal BPF, затем была переименована в Extended BPF, а теперь, по прошествии нескольких лет, все ее называют просто BPF.

Грубо говоря, BPF позволяет запускать произвольный код, предоставляемый пользователем, в пространстве ядра Linux и новая архитектура оказалась настолько удачной, что нам потребуется еще с десяток статей, чтобы описать все ее применения. (Единственное с чем не справились разработчики, как вы можете видеть на кпдв ниже, это с созданием приличного логотипа.)

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

Немного прошерстив Habr удивился тому, что очень мало опубликовано статей на тему (beta-)фичи GitHub'а — Actions.

Казалось бы, можно объяснить такую недосказанность тем, что функционал еще в тестировании, пусть и "beta". Но именно полезная особенность беты позволяет использовать этот инструмент в приватных репозиториях. Именно про работу с данной технологией я расскажу в этой статье.