а что за БД? тип самой колонки – geometry, но в ней лежит полигон?

Mysql

Column type polygon

Подскажите пожалуйста best practice по трансформ стриму - написал что-то очень страшное

кто-нибудь работал с tdlib?

Не наследовать, а использовать открытый конструктор

Кто-то может мне объяснить зачем вот это в NestJS ?

const dbHost = this.configService.get<string>('database.host');
export default registerAs('database', () => ({
  host: process.env.DATABASE_HOST,
  port: process.env.DATABASE_PORT || 5432
}));

когда уже есть

process.env

Я чет не могу понять что они с помощью этих нехитрых решений пытались развязать?

Если не сложно можно ссылку на док? Не могу найти почему-то usage - только странные примеры с zlib

В офф доке все расписано

const dbHost = this.configService.get<string>('database.host');
export default registerAs('database', () => ({
  host: process.env.DATABASE_HOST,
  port: process.env.DATABASE_PORT || 5432
}));

process.env

Убери, если не нужно

const dbHost = this.configService.get<string>('database.host');
export default registerAs('database', () => ({
  host: process.env.DATABASE_HOST,
  port: process.env.DATABASE_PORT || 5432
}));

process.env

Они делают возможность заменить источник конфигов одним нехитрым движением. Если вы завтра решите держать конфиги не в env переменных а например брать их откуда-то HTTP запросом во время старта приложения -  то все равно в коде вы будете все брать из configService.

и вторая цель - тестируемость. если вы везде в коде обращаетесь к configService то в тестах вы просто подмените configService и прогоните тест. а если вы в коде везде обращаетесь к process.env то в тестах будете колдовать с process.env что не есть хорошо

👍 Тогда да, в этом есть смысл. Спасибо, Лена

@tshemsedinov у меня тут глупый вопрос возник. Как вы относитесь к документированию кода? Нужно, или код должен быть "самодокументирующимся"?

Если для понимания кода нужны комментарии, то в 99% случаев это плохой код, а в 1% - это оптимизпции сложного системного кода, который сознательно так написан, потому, что нижестшящий слой нельзя изменить и поиходится подстраиваться

В гошном чате вчера кинули ссылку на интересную статью на Хабре про вопросы с собеседования, и там до сих пор бурлят споры (в комментах хабра скорее всего тоже)
В вопросах довольно много специфики, но чаще всего люди цепляются к одному вопросу, который уместен и для мира ноды: как устроен тип Map?
Сразу процитирую автора: Самый популярный неправильный ответ: «это хеш-таблица». Да, это хеш-таблица. Как устроена хеш-таблица?

Стало любопытно, а насколько часто вы слышали (или задавали) такой вопрос на собеседованиях на позицию разработчика в ноде?

Поясню своё любопытство
Мне кажется, что вопрос хороший (потому что достаточно глубокий). И что на собесах по ноде он не звучит, потому что к разработчикам на ноде предъявляют более низкие требования, чем к разработчикам на других платформах/языках (у меня есть соображения почему так, но ими я пока делиться не хотел бы). Но мало ли, это только мой опыт, и на самом деле такой вопрос на собесе - стандартная практика, а мне просто (не)везло

Ссылка на начало срачика в го чате, если кому интересно будет: t.me/gogetajob/53981

Почему более низкие? Мне кажется что даже наоборот

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

Ну, KISS наверное самый необходимый паттерн в программировании