О частоте релизов

После прочтения continuous integration, delivery и иже с ними выкристаллизировалось:

Редкие по частоте релизы проекта для своего успешного проведения мастерства на уровне искусства. А вот для проведения частых релизов уже нужно немного другое - инженерное мастерство.
Т.е. опять повторение спора художника и ремесленника. Только сейчас у нас разработка программ - это индустрия и инженерное дело. А значит ремесленник в приоритете.

Хотя выстроить процедуру частых релизов - это все ещё искусство... ;)

Stroustrup и 16 способов положить кота в стек

Прочитал статью Страуструпа о стеках и кошках: 

http://isocpp.org/blog/2014/03/sixteen-ways

Казалось бы, написана она ещё в 1990 - что нового можно в ней почерпнуть?.. 

В целом, этот материал сейчас смотрится довольно предсказуемо и подкупает меня, скорее, своей академичностью и полнотой рассмотрения вопроса. 

Но, при внимательном прочтении, начинаешь замечать мелочи, которые играют важную роль. Для меня такой мелочью стал внутренний класс stack_id: 

class stack
{
public:
    class id
    {
        friend stack;
    private:
        int i;
    };
    ...
}; 

Казалось бы мелочь, а ведь сколько проблем доставляли мне в свое время типы идентификаторов, определённые через typedef базовых типов... 

А тут:

• раз, и логическая привязка к основному классу;  
• два, и неприводимость к базовому типу(int/string/etc); 
• три, и неизменяемость его наружными классами, а только передача между различными функциями.  

Красиво же!