26 апреля 2024 года состоялся релиз эффективной многопоточной среды обработки Kafka на Ruby и Rail проекта Karafka 2.4.
Исходный код этого инструментария опубликован на GitHub под лицензией LGPLv3.
В новой версии проекта исправлены ранее обнаруженные ошибки, а также внесены улучшения и изменения. В Karafka 2.4 прекращена поддержка Ruby 2.7 и используется инструментарий WaterDrop 2.7.
Неосознанный отбор
Понятно, зачем крупные компании на собеседованиях проверяют те вещи, которые не нужны на работе. Там откликаются тысячи кандидатов ежедневно и нужно максимально сужать воронку. Но меня удивляют компании среднего размера, которые делают также.
В средних компаниях нет строгих правил по проведению технических интервью. И вся ответственность за то, какое будет это интервью, ложится на плечи интервьюера. Я заметил, что интервьюеры в этом случае действуют по 2 сценариям:
1. Проверяют базу. Перед интервью они сами быстренько нагоняют базу, так как всё уже забыли. И начинается: какие типы знаешь помимо основных, как работают промисы, как можно копировать объект, принципы ООП и так далее.
2. Дают боевые задачи. Как правило, в этом случае интервьюеры особо не готовятся к собеседованию, а готовят только сами задачи. Здесь интервьюер может спросить решение какой-то архитектурной проблемы. Для грейда ниже может попросить разработать какой-то компонент на React. Для собеседования могут браться даже реальные задачи из Jira.
При этом кандидаты тоже делятся на 2 типа:
1 тип готовится к собеседованиям
2 тип не готовится к собеседованиям
Второй тип будет работать хуже? Не думаю
Но главная цель собеседования в среднюю компанию – найти кандидата, который будет максимально круто решать рабочие задачи. Зачем нужно осознанно отметать людей, которые не тратят время на подготовку к собеседованиям, а реально любят и хотят работать?
***
Подписывайтесь на мой телеграм-канал Вайтишная
Go SDK
Будучи скромным гофером хочу отметить, что решение тех или иных задач - требует понимание базы и идиом языка. Конечно, есть замечательная документация, есть не менее замечательный хаб, но пока самые-самые сердечки это репозитория go, где в центре внимания легендарный пакет runtime и sync.
Вот несколько примеров, как описан sync.Map в коде, комментарии к которому и реализация методов отвечает на многие вопросы
//...
// Load, LoadAndDelete, LoadOrStore, Swap, CompareAndSwap, and CompareAndDelete
// are read operations; Delete, LoadAndDelete, Store, and Swap are write operations;
// LoadOrStore is a write operation when it returns loaded set to false;
// CompareAndSwap is a write operation when it returns swapped set to true;
// and CompareAndDelete is a write operation when it returns deleted set to true.
type Map struct {//...
// Range may be O(N) with the number of elements in the map even if f returns
// false after a constant number of calls.
func (m *Map) Range(f func(key, value any) bool) {
// We need to be able to iterate over all of the keys that were already
// present at the start of the call to Range.
// If read.amended is false, then read.m satisfies that property without
// requiring us to hold m.mu for a long time.
read := m.loadReadOnly()
if read.amended {
// m.dirty contains keys not in read.m. Fortunately, Range is already O(N)
// (assuming the caller does not break out early)...
...Всем приятного копания базы и профессионального роста.
В стандартной C-библиотеке Glibc выявлена уязвимость (CVE-2024-2961), приводящая к переполнению буфера при преобразовании специально оформленных строк в кодировке ISO-2022-CN-EXT функцией iconv().
Выявивший проблему исследователь 10 мая выступит на конференции OffensiveCon с докладом, в анонсе которого упоминается возможность эксплуатации уязвимости через приложения на языке PHP. Проблема затрагивает всю экосистему PHP и некоторые приложения.
При преобразовании строк в кодировке UCS4, в соответствии с требованиями RFC 1922, библиотека Glibc добавляет некоторые escape-символы, выделяющие части строки, в которых кодировка была изменена.
Уязвимость в вызвана некорректной проверкой границ внутренних буферов функцией iconv(), что может привести к переполнению буфера максимум на 4 байта. При переполнении за границу буфера могут быть записаны определённые фиксированные значения, такие как '$+I', '$+J', '$+K', '$+L', '$+M' и '$*H'. Несмотря на то, что эксплуатация подобной уязвимости для выполнения кода кажется маловероятной, этого оказалось достаточно для подготовки нескольких прототипов эксплоитов для удалённой атаки на PHP-приложения, приводящей к выполнению кода.
Уязвимость проявляется с 2000 года и устранена в находящейся в разработке ветке Glibc 2.40. Исправление также доступно в виде патчей для выпусков Glibc с 2.32 по 2.39. В дистрибутивах проследить за исправлением уязвимости можно на страницах: Debian, Ubuntu, Gentoo, RHEL, SUSE, Fedora, Arch.
Источник: OpenNET.
В размышление о статье "Нужны ли программистам алгоритмы?".
Проблема не в том, нужны или не нужны алгоритмы, а в том, что в России нет развитой айтишной школы, как в США. Нет того уровня образования (как в Калтехе, к примеру). То, что есть сейчас - это прям скажем, беда. Натягивание советской школы на новые реалии. Настолько, что Яндекс даже создает свои учебные заведения, чтобы получить хоть каких-то вменяемых специалистов.
Нужны не знания алгоритмов. Нужны специалисты с инженерным мышлением. У человека без образования мышление хаотичное, несистемное. Он не способен на анализ, упрощение и синтез. Грубо говоря, лупит код, как бог на душу положит, чем больше, тем лучше.
Вебмониторэкс приглашает вас 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 из файлов доступных репозиториев исходного кода.