Возможно, вы понимаете как писать хороший код, как придерживаться хорошего дизайна. Но структурировать эти знания не получается. Книга Джона Оустерхаута “A philosophy of software design” может помочь исправить это.

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

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

Всемирная организация здравоохранения недавно обновила определение профессионального выгорания в своем справочнике медицинских диагнозов. На фоне развития удаленной работы из-за коронавируса симптомы заболевания стали появляться всё чаще. Раньше выгорание характеризовали как «синдром общего стресса». Теперь — как «синдром… возникающий в результате хронического стресса на рабочим месте, с которым не удалось успешно справиться». ВОЗ описывает три симптома выгорания на работе:

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

Я дважды становился тимлидом

int main()
{
	int n = 500000000;
	int *a = new int[n + 1];
	for (int i = 0; i <= n; i++)
		a[i] = i;
	for (int i = 2; i * i <= n; i++)
	{
		if (a[i]) {
			for (int j = i*i; j <= n; j += i) {
				a[j] = 0;
			}
		}		
	}
	delete[] a;
	return 0;
}

Важно: для комфортного прочтения статьи нужно уметь читать исходный код на Rust и понимать, почему оборачивать всё в Rc<RefCell<...>> — плохо.

Введение

Rust не принято считать объектно-ориентированным языком: в нём нет наследования реализации; инкапсуляции на первый взгляд тоже нет; наконец, столь привычные ООП-адептам графы зависимостей мутабельных объектов здесь выглядят максимально уродливо (вы только посмотрите на все эти Rc<RefCell<...>> и Arc<Mutex<...>>!)

Правда, наследование реализации уже как несколько лет считают вредным, а гуру ООП говорят очень правильные вещи вроде "хороший объект — иммутабельный объект". Вот мне и стало интересно: насколько хорошо объектное мышление и Rust сочетаются друг с другом на самом деле?

Первым подопытным кроликом станет паттерн State, чистой реализации которого и посвящена эта статья.

Так как ClickHouse является специализированной системой, при его использовании важно учитывать особенности его архитектуры. В этом докладе Алексей расскажет о примерах типичных ошибок при использовании ClickHouse, которые могут привести к неэффективной работе. На примерах из практики будет показано, как выбор той или иной схемы обработки данных может изменить производительность на порядки.