Программирование *

Языку программирования BASIC исполнилось 60 лет. 1 мая 1964 года в Дартмутском колледже в США математики Джон Кемени (John G. Kemeny) и Томас Курц (Thomas E. Kurtz) успешно запустили первую программу на их недавно разработанном языке программирования BASIC (Beginner's All-Purpose Symbolic Instruction Code) на принадлежащем колледжу мейнфрейме General Electric GE-265 с поддержкой множества терминалов. Вопреки распространённому убеждению, в момент своего появления это был компилируемый язык.

BASIC был создан как инструмент, с помощью которого студенты-непрограммисты могли самостоятельно создавать компьютерные программы для решения собственных задач.

При проектировании языка использовались следующие восемь принципов. Новый язык должен был:

• быть простым в использовании для начинающих;

• быть языком программирования общего назначения;

• предоставлять возможность расширения функциональности, доступную опытным программистам;

• быть интерактивным;

• предоставлять ясные сообщения об ошибках;

• быстро работать на небольших программах;

• не требовать понимания работы аппаратного обеспечения;

• защищать пользователя от операционной системы.

В конце 70-х и начале 80-х годов BASIC оставался программным интерфейсом и квази-ОС для популярных домашних компьютеров Atari 800, TRS-80, Commodore VIC-20, Commodore 64, ZX Spectrum, TI-99/4A, BBC Micro и IBM PC.

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

31 июля 2020 года влогер MattKC опубликовал видеоролик, в котором попытался уместить игру в QR-коде. В результате он написал вариант «Змейки», которая занимает 2953 байта. Исполняемый файл такого размера возможно уместить в QR-коде, поскольку этот формат кодирует до 3 КиБ данных.

Эксперимент влогера не остался без внимания. Уже 3 августа свой вариант показал Брайан Каллахан. Эта «Змейка» требует всего 2024 байта. Впрочем, вариант MattKC ужимается с помощью Crinkler до 1,4 КиБ.

Дальнейшие эксперименты ушли ниже тысячи, а потом и сотни байтов. В последние месяцы развернулась борьба за каждый байт. В ноябре 2023 года удалось заменить ассемблерную инструкцию и выиграть целый байт. Ещё два байта сэкономили две недели назад за счёт замены jae и xor на adc.

Итоговый вариант — это «Змейка» на 58 байт для Microsoft DOS. Для сравнения: ничего не выполняющая программа на C gcc -Os -w -xc - <<< "main;"на 64-битном Linux займёт 15 776 Б. 58 байт — это немного даже для текстовых данных: хватит на небольшое предложение или последовательность эмодзи по типу «??‍❤️‍?‍????‍♀️??‍❤️‍?‍??».

Конечно, в QR-коде эта игра тоже уместится. Также автор выложил онлайн-демку (управление по стрелкам клавиатуры на ПК или свайпу на мобильных устройствах).

github.com/donno2048/snake

Лучший способ самопрокачки для инженеров

Я считаю, что лучший способ прокачать свои скиллы - это сделать сайд-проект.

Часто встречаю убеждение, что учиться/саморазвиваться - это про чтение книжек, прохождение курсов и тд. Однако теория без практики мертва, практика без теории слепа. Прочтение кучи книжек и прохождение кучи курсов делает человека эрудированным, а не крутым спецом.

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

Сайд-проекты делать можно и нужно вообще на любых уровнях. Они одинаково полезны и совсем зелёным новичкам, и матёрым разработчикам. Разница только в уровне сложности и целевых навыках.

Я за свою карьеру сделал огромную пачку сайд-проектов. Какие-то были неудавшимися стартапами, другие же я делал с целью разобраться в конкретной теме. Свой первый сайд-проект я сделал ещё до получения первой официальной работы - это был RSS-ридер на C# и WPF.

Когда я был джуном, то мы с более опытным коллегой загорелись идеей сделать свой стартап. По выходным мы собирались у него и херачили. Стартап не пошёл, но за полтора года работы над ним я получил колоссальный буст к скиллам разработки.

И даже сейчас я продолжаю делать сайд-проекты. Один из них вы читаете прямо сейчас ?

Больше интересного про жизнь в IT у меня в ТГ

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.

https://documentation.divio.com

Шаблон декомпозиции 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,
		}
	}
	
}

✅ Удобно из модели получать любые отображения.
❌ Добавление нового отображения требует изменения модели.
❌ Отображение полностью определяется одной основной моделью.
❌ Загрузка модели вытягивает по зависимостям и все её отображения.
❌ Двух слоёв слишком мало на больших масштабах.