А никак они не развивались. С самых первых языков программирования и по сей день комментарии коду — это всего лишь статичный текст (за некоторыми исключениями, о которых я расскажу).
Ну а что там еще можно улучшить или придумать — спросите вы. Давайте поразмышляем на эту тему — можно ли как-то улучшить наш опыт взаимодействия с таким важным но так часто игнорируемым аспектом программирования как документация в коде, или по-простому комментарии.
Читать полностью »
Привет! Меня зовут Алексей Пьянков, я главный программист в компании Спортмастер. Скажу сразу, что «главный» не значит «самый главный из всех программистов», нет, это только название, такой очаровательный перевод для «Senior+"».
В компании Спортмастер я работаю с 2012 года, и за это время командой разработки было сделано много решений, интересных с технической стороны. Но сегодня я бы хотел рассказать о нашей работе с акцентом скорее на том, как мы рассуждали в определенных неоднозначных ситуациях.
В этой статье не будет конкретных технических решений (да и вообще чего-то технического), которые следует хватать и применять у себя в проекте. Скорее — это рефлексия по проделанной работе. Были такие особые моменты, которые повлияли на нас как на команду — сплотили, закалили и проверили на прочность. Об этих моментах, об атмосфере работы в команде, о наших граблях и ряде психологических ловушек, в которые мы сами себя иногда загоняем, я и попробую сегодня рассказать.
И начну именно с 2012 года.
Первая часть, судя по комментариям вызвала неоднозначное мнение, особенно что касалось части enum. Где-то я так же могу не соглашаться, как с автором оригинала, так и с некоторыми комментариями. Но как и указывалось в начальном описании к первой части, чистый код это не догма которую нужно соблюдать, это всего лишь рекомендации, соблюдение которых каждый сам выбирает под свои потребности и взгляды.
Как быть, если дерево поиска разрослось на всю оперативку и вот-вот подопрет корнями соседние стойки в серверной? Что делать с инвертированным индексом, жадным до ресурсов? Завязывать ли с разработкой под Android, если пользователю прилетает «Память телефона заполнена», а приложение едва на половине загрузки важного контейнера?
В целом, можно ли сжать структуру данных, чтобы она занимала заметно меньше места, но не теряла присущих ей достоинств? Чтобы доступ к хэш-таблице оставался быстрым, а сбалансированное дерево сохраняло свои свойства. Да, можно! Для этого и появилось направление информатики «Succinct data structures», исследующее компактное представление структур данных. Оно развивается с конца 80-х годов и прямо сейчас переживает расцвет в лучах славы big data и highload.
Если ваши микросервисы уже используют общую базу PostgreSQL для хранения данных, или ей пользуются несколько экземпляров одного сервиса на разных серверах, можно относительно «дешево» получить возможность обмена сообщениями (PubSub) между ними без интеграции в архитектуру Redis, RabbitMQ-кластера или встройки в код приложения другой MQ-системы.
Для этого мы не будем писать сообщения в таблицы БД, поскольку это вызывает слишком большие накладные расходы сначала на запись передаваемого, а потом еще и на зачистку от уже прочитанного.
Передавать и получать данные мы станем с помощью механизма NOTIFY/LISTEN, а модельную реализацию соберем для Node.js.
Но на этом пути лежат грабли, которые придется аккуратно обойти.
Читать полностью »
Доброго времени суток, друзья!
Дисклеймер: дальнейшее повествование носит юмористический. Все персонажи являются вымышленными, все совпадения случайны.
Наследование (биология) — передача генетической информации (генетических признаков) от одного поколения организмов к другому — Википедия
Наследование (программирование) — концепция объектно-ориентированного программирования, согласно которой абстрактный тип данных может наследовать данные и функциональность некоторого существующего типа, способствуя повторному использованию компонентов программного обеспечения — Википедия
В некотором царстве, в некотором государстве… короче, жили-были три воробья: воробей-дед, воробей-отец и воробей-сын. Были они, значит, воробьями, каждый имел две лапки и хвостик:
Читать полностью »
Я хотел написать этот пост ещё в июле, но никак не мог, о ирония, решить, как его назвать. Удачные термины пришли мне в голову только после доклада Кейт Грегори на CppCon, и теперь я наконец могу рассказать вам, как не надо называть функции.
Бывают, конечно, названия, которые вообще не несут информации, типа int f(int x). Ими пользоваться тоже не надо, но речь не о них. Порой бывает, что вроде бы и информации в названии полно, но пользы от неё абсолютно никакой.
Меня всегда раздражало, что я не могу запустить 64-битную игру на C# под MS-DOS. Сегодня я это исправил.
Сотрудник компании Red Hat Ричард Джонс, создатель библиотеки libguestfs, представил инструмент Goals, цель которого — устранить недостатки в утилите make, разработанной Стюартом Фельдманом в 1976 году и предназначенной для автоматизации преобразования файлов из одной формы в другую. Читать полностью »
Давно, ещё в 1960-х, Гордон Мур, один из основателей компании Intel, заметил, что количество транзисторов, которые можно уместить на кремниевом чипе, удваивается примерно каждые два года. Поскольку количество транзисторов связано с вычислительной мощностью, это означало, что, по сути, вычислительная мощность удваивается каждые два года. Так родился закон Мура, обеспечивший для работающих в компьютерной индустрии людей – по крайней мере, для тех, кому ещё нет сорока – такую же надёжную основу, какую ньютоновские законы движения обеспечели для инженеров-механиков.
Читать полностью »
