
Программирование *
Искусство создания компьютерных программ
Вебмониторэкс приглашает вас 17 апреля в 12:00 (мск) на вебинар, во время которого мы раскроем тему значимости обеспечения безопасности API в современных условиях.
Ведущие вебинара - Лев Палей, CISO и Сергей Одинцов, системный аналитик Вебмониторэкс.
Расскажем об изменении ландшафта угроз и отражении этих изменений в OWASP API Security.
Подробно рассмотрим обеспечение безопасности веб-приложений в наиболее атакуемых отраслях (телекоммуникационные компании и интернет платформы).
Покажем, как платформа «Вебмониторэкс» решает задачи по защите веб-приложений и API.
Почему полезно:
- Узнаете о новых уязвимостях в OWASP API Security и вариантах их эксплуатации
- Получите рекомендации по защите своих API
- Увидите примеры, иллюстрирующие изменения OWASP API Security
Продолжительность вебинара 1 час 30 минут!
Регистрируйтесь на вебинар по ссылке.
Приглашаем на день открытых дверей онлайн-магистратуры Яндекс Практикума!
→ Бесплатный вебинар 10 апреля в 18:00
Расскажем про восемь IT-программ онлайн-магистратуры совместно с ведущими вузами, на которые можно поступить в 2024 году. В списке партнёров — ИТМО, НИТУ МИСИС, РАНХиГС, ТГУ и Финансовый университет.
Спикеры:
Сергей Бережной, директор по взаимодействию с разработчиками в Яндексе;
Анастасия Ждановская, руководитель программ высшего образования в Яндекс Практикуме;
Павел Шлюпкин, старший IT-рекрутер в Яндекс 360;
Елена Шоломова, менеджер команды сопровождения в Практикуме.
Кому будет полезно:
Всем, кто хочет получить магистерское образование в сфере IT;
Всем, кому важно получить диплом государственного образца;
Выпускникам бакалавриата и специалитета любых направлений подготовки.
Шаблон декомпозиции ModelView Fractal
Каждый ModelView выступает в роли модели/контроллера для ведомых ModelView и в качестве отображения для владеющего ModelView. Часть логики может выноситься как в чистые Model, так и в чистые View, которые являются лишь вырожденными случаями ModelView.

$my_user_list $my_view
- \Owner ModelView
users? /$my_user
kids /
<= Row*0 $my_user_row
user <= user*
$my_user_row $my_card
- \Having ModevView
user $my_user
avatar => image
nickname => message
$my_card $my_view
- \View not Model
kids /
<= Image $my_image
uri <= image \about:blank
<= Message $my_text
text <= message \
$my_user $my_model
- \Model not View
avatar? \
nickname? \✅ Каждый ModelView полностью контролирует внутренние ModelView и ничего не знает про внешние.
✅ Любой ModelView может шариться между разными другими ModelView на любом уровне композиции.
✅ Изменение интерфейса ModelView требует изменения только лишь его владельцев.
✅ Фрактальная структура легко масштабируется на приложения любого размера.
Шаблон декомпозиции Model-View-Presenter
Модели и отображения пассивны, и не знают друг о друге - они управляются презентером, который выступает и в качестве посредника между ними.

// Presenter
class User_preview {
user: User
card = new Card({
image: ()=> this.user.avatar,
message: ()=> this.user.nickname,
color: ()=> this.user.skin.color,
click: ()=> this.skin_change(),
})
skin_change() {
this.user.skin = Skin.random()
}
}
// View
<div class="Card" onclick={click} style={{ background: color }}>
<img src={ image } />
<p>{ message }</p>
</div>
// Model
class User extends Model {
avatar: string
nickname: string
skin: Skin
}
✅ Легко добавлять новые отображения, не меняя модели. И наоборот.
✅ Изменение интерфесов модели или отображения требует изменения только лишь презентеров.
❌ Трёх слоёв слишком мало на больших масштабах.
❌ Для использования состояния одного презентера из другого необходимо искусственное вынесение его в модели.
Недавно набрёл на интересный сайт с описанием системы документирования. Речь идёт не о системе подготовки документации, а именно о принципах и подходах в документировании. Меня просто заворожила простота, ясность и лаконичность как самой системы, так и её изложения. Прочитать можно буквально за полчаса.
Уверен чтение будет интересно и полезно всем, кто сталкивается с необходимостью заниматься документированием проекта, библиотеки, фреймворка.
There is a secret that needs to be understood in order to write good software documentation: there isn’t one thing called documentation, there are four.
They are: tutorials, how-to guides, technical reference and explanation. They represent four different purposes or functions, and require four different approaches to their creation. Understanding the implications of this will help improve most documentation - often immensely.

Шаблон декомпозиции Model-View-Controller
Контроллер создаёт отображение, и говорит ему с какой моделью работать. Так же он обрабатывает все команды от пользователя, и управляет своими подопечными.

// Controller
class Users_resource {
GET() {
return User.all.map( user_brief )
}
}
// View
function user_brief( user: User ) {
return {
id: user.guid,
name: user.passport.name_full,
}
}
// Model
class User {
static all = [] as User[]
guid: GUID
passports: Passport[]
resumes: Resume[]
get passport() {
return this.passports[0]
}
}✅ Отображение может использовать произвольные модели с тем же интерфейсом.
✅ Легко добавлять новые отображения, не меняя модели. И наоборот.
❌ Для отображения разных типов моделей необходимо дублировать код отображения.
❌ Изменение интерфейса модели требует обновления всех использующих её отображений и контроллеров.
❌ Трёх слоёв слишком мало на больших масштабах.
Шаблон декомпозиции Model-View-ViewModel
Отображения работают с моделями через посредников, которые трансформируют абстракции предметной области в абстракции отображения и обратно. ViewModel также выступает хранилищем состояния отображения, не связанного с предметной областью.

// View
<li class="User_card" model="User_card_model">
<img src={ image } />
<p>{ message }</p>
</li>
// ViewModel
class User_card_model {
user = User.current
get image() {
return this.user.avatar
}
get message() {
return this.user.nickname
}
}
// Model
class User {
avatar: string
nickname: string
static current = new User
}
✅ Отображение может использовать произвольные вьюмодели.
✅ Легко добавлять новые отображения, не меняя ни модели, ни вьюмодели.
✅ Изменение интерфейса модели или отображения требует изменения только лишь вьюмодели.
✅ Одну и ту же вьюмодель можно шарить между несколькими отображениями.
❌ Для отображения разных моделей необходимо дублировать код отображения и вьюмодели.
❌ Трёх слоёв слишком мало на больших масштабах.

Привет, я Иван Елфимов, Developer Advocate в Ostrovok.ru. Расскажу про наш переход на Django 5.0.
4 марта вышел третий security release, когда мы обычно переходим на новые версии библиотек. Мы были готовы к переходу: проверили на декабрьском 5.0.0. что могло сломаться. Из-за некоторых обновлений нам пришлось менять код:
Раньше мы использовали
nulls_last=False. Теперьnulls_firstиnulls_lastмогут бытьTrueилиNone, поэтому в некоторых местах вместо значений по умолчанию теперьnulls_last = None:
- nulls_last = False
+ nulls_last = None
if ordering_by == OrderingField.FIELD_START_AT:
nulls_last = TrueВ сигналах появился новый тип асинхронных ресиверов (
async_receivers), мы добавили его во вспомогательный классSignalBlocker, которым временно выключаем сигналы.Теперь надо явно указывать
USE_TZ = False, но это не проблема, мы не используем таймзоны в нашем сервисе.Если после
refresh_from_dbнадо дальше по коду использовать закешированные значения из базы данных, появился такой хак:
my_model_obj._meta.private_fields = []
my_model_obj.refresh_from_db()Новинка, которой воспользуемся в будущем, — расчетные поля по умолчанию (default) в БД. Есть сценарии, где нужно, чтобы поле по умолчанию было не скаляром, а содержало расчётное значение на основе других полей.
Шаблон декомпозиции View-Model
Код работы с моделями пишется прямо в отображении.

// View
function Task_list() {
return <ul>{
Task.list.map( task =>
<li><Task_row {task} /></li>
)
}</ul>
}
// Model
class Task {
static list = [] as Task[]
}
✅ Отображение может использовать произвольные модели.
✅ Легко добавлять новые отображения, не меняя модели.
❌ Для отображения разных моделей необходимо дублировать код отображения.
❌ Изменение интерфейса модели требует обновления всех использующих её отображений.
❌ Двух слоёв слишком мало на больших масштабах.
Нео из «Матрицы» или бородатый программист? ?
Узнайте, какой вы стереотипный айтишник

Вместо однотипных шуток принесли вам первоапрельский тест. Советуем проходить его с осторожностью: по результатам квиза редактор этого канала пересмотрел приоритеты и улетел отдыхать в Сочи ?
Переходите по ссылке, смело повторяйте его ошибки, а потом возвращайтесь в комментарии и делитесь результатами ⬇️
Шаблон декомпозиции Model-View
Модель знает как себя по разному представлять.

class User { // Model
_id: bigint
_nickname: string
toString() { // View
return 'user=' + this._id
}
toJSON() { // View
return {
id: String( this._id ),
name: this._nickname,
}
}
}✅ Удобно из модели получать любые отображения.
❌ Добавление нового отображения требует изменения модели.
❌ Отображение полностью определяется одной основной моделью.
❌ Загрузка модели вытягивает по зависимостям и все её отображения.
❌ Двух слоёв слишком мало на больших масштабах.

Команда Honeypot выпустила документальный фильм об истории Node.js. В часовом видео подробно рассказали о том, как создавали популярную среду выполнения кода на JavaScript. Фильм продолжает серию, в которой уже есть следующие документальные картины:
Ближайшие события
27 и 28 марта в Лондоне проходила конференция Rust Nation 24. На конференции выступал Ларс Бергстром [Lars Bergstrom], который занимает в Google пост технического директора. Доклад Ларса носил название «Beyond Safety and Speed: How Rust Fuels Team Productivity» (дословно «Кроме безопасности и скорости: как Rust заряжает команду продуктивностью»).
Во время выступления технический директор Google заявил, что команды Rust в Google в два раза продуктивнее команд C++. Этот мощный посыл успел разлететься фотографией с конференции.

Ларс пояснил, что подразумевается под производительностью. Google — компания, где часто переписывают проекты, а иногда две команды работают над похожими задачами. Поэтому подобный анализ в масштабах Google возможен.
Как выяснилось, на переписывание на Rust нужно примерно столько же времени и людей, сколько уходит на написание продукта на Go. При этом памяти приложения на Rust используют куда меньше, в них меньше дефектов. Когда компонент на C++ переписывают на Rust при одинаковом размере команд, в два или более раз сокращаются время и усилия как для написания, так и поддержки кода.
Слегка портит картину то, что Бергстром — это ещё и председатель совета директоров Rust Foundation, поэтому делать такие заявления он непосредственно заинтересован.
На записи видеотрансляции с конференции обсуждение деталей производительности идёт с отметки 7:30:13.
Проверьте, используются ли ваши репозитории GitHub и исходный код ваших проектов для обучения различных больших языковых моделей (БЯМ — LLM).
На huggingface появилась вторая версия проекта Stack. Это открытый интерфейс управления между сообществом искусственного интеллекта и сообществом открытого исходного кода.

В рамках проекта BigCode выпущен и поддерживается The Stack V2 — набор данных исходного кода объёмом 67 ТБ для более чем 600 языков программирования. Одна из целей в этом проекте — предоставить людям свободу действий в отношении их исходного кода, позволяя им решать, следует ли использовать его для разработки и оценки моделей машинного обучения, поскольку сообщество признает, что не все разработчики могут захотеть, чтобы их данные использовались для этого.
Этот инструмент позволяет проверить, является ли репозиторий под именем пользователя частью набора данных The Stack. Хотели бы вы удалить свои данные из будущих версий The Stack? Вы можете это сделать, следуя инструкциям здесь.
Примечание. Stack v2.0 создан на основе общедоступного кода GitHub, предоставленного Software Heriage Archive. Он может включать репозитории, которых больше нет на GitHub, но которые были ранее заархивированы Software Heritage. Перед обучением моделей StarCoder 1 и 2 был запущен дополнительный конвейер PII для удаления имён, адресов электронной почты, паролей и ключей API из файлов доступных репозиториев исходного кода.
Эксперт Джон Джаго назвал два проекта с открытым исходным кодом, у которых разработчиками собрана и представлена исключительная техническая документация, включая высокую детализацию кода и архитектуры. Это esbuild и Redis.
По мнению Джаго, через файлы README, журналы изменений, архитектурные документы и комментарии к коду оба эти проекта объясняют свой дизайн таким образом, чтобы даже новичок может понять в кодовой базе, где что находится, как что-то делается и почему это делается именно так. Он порекомендовал разработчик, желающим лучше документировать свой код и архитектуру программного обеспечения, брать для примера эти проекты.

Преимущества хорошей документации:
экономия времени на работы с кодом, особенно если работаете командно, не нужно дополнительно объяснять всю кодовую базу каждому разработчику;
такой проект с открытым исходным кодом с большей вероятностью получит поддержку со стороны и, следовательно, продолжит своё существование даже после того, как автор больше не сможет его поддерживать;
прошлые ошибки и решения, которые подвергались сомнению, записаны, что не позволяет случайно повторно привести к проблеме, которую помогло решить прошлое решение;
приложение или библиотеку смогут использовать больше людей, поскольку меньшему количеству из них придётся во всем разбираться самостоятельно;
это помогает структурировать ваше мышление и выявить недостатки. Когда вы пишете, вам необходимо чётко обдумывать и записывать то, что вы думаете, и это выявляет потенциальные проблемы.
Одна из самых серьезных проблем в разработке программных средств — их тучность, или раздутость. Программы просто становятся слишком большими. Это может быть связано с неразумным выбором функций, но чаще всего становится следствием плохой архитектуры. Популярное средство повторного использования кода — наследование, но его работа оставляет желать лучшего, поэтому вместо него зачастую применяются копирование и вставка кода. Не следует сбрасывать со счетов и чрезмерную зависимость от библиотек, платформ и пакетов, тесно связанных со многими другими библиотеками, платформами и пакетами. Раздутость может быть побочным эффектом приемов гибкой разработки. Чтобы справиться с ней, увеличивают численность команды разработчиков, но это порождает еще большую раздутость.
…
Лучший способ справиться с раздуванием программ — не допускать его. Приоритетом при разработке и реализации программы нужно сделать ее «худобу». Следует избегать внедрения в практику раздутых пакетов и инструментов, способствующих раздуванию. Обходитесь без классов. Нанимайте небольшие квалифицированные команды разработчиков. И активно практикуйте удаление кода. Создайте резерв из нескольких циклов разработки с целью удаления ненужного кода и избавления от проблемных пакетов. Радуйтесь, когда количество строк кода в проекте уменьшается. Придерживайтесь принципа наименьшей раздутости.
Дуглас Крокфорд, программист, автор формата JSON и книги "How JavaScript Works"
Разработчик под ником punkx представил список игр, пазлов и головоломок, чтобы научить своего ребенка программированию.

В список вошли (по ссылкам есть pdf с карточками игр для свободной печати, а также описание правил и игровые видео):
Оплачиваемая стажировка Cloud.ru для AppSec-инженеров — набор до 6 апреля 📢

Присоединяйтесь к AppSecCamp — оплачиваемой стажерской программе, которая поможет начинающим IT-специалистам прокачаться в одной из самых востребованных областей на стыке разработки ПО и информационной безопасности.
За три месяца вы:
прокачаете навыки безопасной разработки приложений;
научитесь определять уязвимости в коде на языках Go, Python, JavaScript, TypeScript и других;
получите опыт работы с SAST-, DAST- и SCA-инструментами;
научитесь проводить моделирование угроз и security code review.
Прием заявок на AppSecCamp открыт до 6 апреля включительно, а для прошедших этапы отбора стажировка начнется 13 мая. Пройти стажировку можно очно — в офисе Cloud.ru в Москве, а также удаленно из любой точки РФ.
А в статье можно почитать о результатах и впечатлениях участников стажировок Cloud.ru в 2023 году. Используйте шанс погрузиться в реальные проекты, обучиться актуальным технологиям и продолжить работу в крутой компании.
Еще полезное в блоге:
Как разработчики решали одну маленькую, но NP‑полную проблему — поделимся на конференции GoCloud про облака 📝

Что общего между загрузкой транспортных контейнеров на судно и грамотным формированием портфеля ценных бумаг? Все это задачи комбинаторной оптимизации, которые можно свести к спиновой модели. Квантового компьютера под рукой не оказалось, зато были две Tesla V100 с кучей памяти и тензорных ядер, методы линейной алгебры, альфа-бета отсечение и фортрановские библиотеки. Не то чтобы все это было необходимо, но хотелось найти точное решение, которым ведущий разработчик Cloud.ru Александр Мальцев поделится на конференции GoCloud.
📌 Тема: Кейс: как решить одну маленькую, но NP‑полную проблему
📅 Когда: 21 марта в 15:30 мск
Что еще интересного будет на GoCloud, смотрите в программе конференции.
Полезное в блоге: