Заблуждения относительно работы пагинации

Нашел на просторах сети список, хочу поделиться с вами:

1. Количество элементов на странице фиксировано навсегда.
2. Количество элементов на странице фиксировано для одного пользователя.
3. Количество элементов на странице фиксировано для одного набора результатов.
4. Страницы просматриваются только в одном направлении.
5. Ни один элемент не будет добавлен в набор результатов во время его извлечения.
6. Ни один элемент не будет удалён из набора результатов во время его извлечения.
7. Порядок сортировки элементов остаётся стабильным.
8. За один раз будет извлечена только одна страница результатов.
9. Страницы будут извлекаться по порядку.
10. Страницы будут извлекаться своевременно.

3 раза я был в подлодке в качестве гостя. Пришла пора отплатить ребятам и в этот раз я позвал на подкаст Катю, с которой мы поговорили про подкастинг. Как ребята стартовали и шли к успеху, когда почувствовали, что пришел успех и как их нагнал хейт. В подкасте мы обсуждаем все от технических деталей организации своего подкаста до влияния на индустрию. https://www.youtube.com/watch?v=Lwgmz7qVXEM

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

Развитие сюжета про Василия
Когда я начал пост, то планировал как можно быстрее объяснить общие принципы работы бизнесов и нырнуть в особенности связанные с расчетом расходной части куда входит ФОТ. В процессе затянуло и стало интересно писать историю, через которую можно показать не только статическое устройство бизнеса, но и стадии его развития, с попутным объяснением ключевых концепций на разных этапах. Одна из вещей которую я точно хочу показать, это разницу между стартапом и сложившимся бизнесом и переход от одной стадии к другой.

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

Чтобы дальше было легче двигаться, мне интересно поболтать с вами на тему своих бизнесов. Были ли у вас такие мысли или попытки. Чего вы боитесь, чего вы не знаете, но хотели бы узнать, что вы не понимаете. Я накину список тем, которые имеет смысл обсуждать в рамках бизнесов:

⁃ Финансовое планирование
⁃ Управленческая отчетность (p&l, баланс, кешфлоу, кассовый метод или метод начислений)
⁃ Юнит-экономика (cac, ltv, arpu, churn rate)
⁃ Маркетинг (перфоманс, посевы, ctr, cpa, crm, посадочные, упаковка, seo)
- Аналитика (сквозная аналитика, аналитика продаж, продуктовая аналитика)
⁃ Продажи
⁃ Менеджмент (KPI, дерево метрик)
⁃ Рынки (рост, алый океан, product marketing fit, конкуренты)
⁃ Продукт

Ссылки: Телеграм | Youtube | VK

p.s. Следующую часть планирую написать завтра или на выходных

Именование в программировании

В этом посте я разберу наиболее общие правила, принятые в среде разработчиков. Для примеров будет использоваться javascript, но это не принципиально. Рекомендации подходят для всех.

Нотация

Перед тем, как говорить о семантике, давайте посмотрим на синтаксис. Существует несколько популярных нотаций именования:

• Верблюжья нотация (CamelCase): myClass
• Змеиная нотация (snake_case): my_const
• Шашлычная нотация (kebab-case): my-data
• Особняком стоит Венгерская нотация

В реальности их гораздо больше, хотя многие вышли из обихода и не употребляются, либо употребляются крайне редко (по крайней мере, вряд ли многие помнят COBOL-CASE).
Возникает вопрос, какой выбрать стиль? Ответ очень прост. В каждом конкретном языке программирования существует общепризнанный — часто официальный — стандарт кодирования. Именно он должен являться для вас ориентиром. Потратьте время, найдите стандарт для вашего языка и пробегитесь по нему, обычно он лежит на гитхабе и содержит большое количество показательных примеров.

Размер имеет значение

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

Сущность-Действие
Сравните:

```

bed(); // bad
sleep(); // good

```

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

Предикаты

Напомню, что предикат — это функция-проверка, она всегда возвращает либо true, либо false.
В большинстве языков предикаты предваряют префиксом is.

```

isEmpty()
isValid()
isBusy()

```

Но не все языки следуют этому правилу. В большинстве лиспов, а так же в ruby (который взял это из лиспов) используется знак ? в конце слова:

```

empty?
valid?
busy?

```

Если учесть, что в указанных языках вызов функции не требует скобок в конце, то такая форма смотрится особенно естественной.

Вхождение

Не все предикаты можно выразить через is. Например, как задать вопрос, если мы хотим узнать, есть ли в списке чисел нечетное? В таких ситуациях принято использовать слово has:

```

node.hasChildren()

```

Количество

Если вам нужна переменная, в которой содержится количество чего-либо, используйте комбинацию: сущность во множественном числе + count.

```

symbolsCount
peopleCount

```

Это правило важнее даже в другом варианте, а именно, как не надо называть переменную, обозначающую количество:

```

errors

```

Такое именование гарантированно вводит в заблуждение. Сущность во множественном числе всегда должна обозначать только коллекцию.

Примеры

```

// Нормализация данных
normalizeDomainName('hexlet.io');

// Извлечение части данных
getName(user);
getDomainFromEmail('[email protected]');

// Получение массива с ошибками
const errors = validate(user);
if (errors.length > 0) {
// ...
}

// Подсчеты
calculateDiff(first, second)

// Допуск
canSwim(user)
canViewProfile(user)

```

p.s. Как бы вы назвали переменную, содержащую массив цен разных товаров после применения скидки?

Ссылки: Телеграм | Youtube | VK

Помните я недавно делал подборку вопросов для трудоустройства? Тот тред хорошо зашел, поэтому пробуем еще раз. В этот раз со спецификой под конкретную тему:

1. Предположим что вам надо раздавать большие файлы из приложения (а не напрямую через nginx). Как это организовать так, чтобы файлы не забивали память?
2. Раздаваемые файлы должны иметь ограничения на уровне приложения, например владение определенным пользователем. Как реализовать подобную авторизацию?
3. Как организовать хранение загруженных файлов на диске? Проблема в том что их нельзя просто так складывать в какую-то папку, потому что при большом количестве, чтение таких директорий начнет сильно тормозить.
4. Как бы вы организовали генерацию Thumbnails для загружаемых картинок? Уточнение: читают в 10 раз чаще чем грузят. Размеры картинок регулярно меняют так как меняется дизайн.
5. Как бы вы подходили к вопросу ускорению скорости загрузки и более эффективному использованию каналов, если бы ваши файлы часто скачивали в физически удаленных локациях? Хотя бы общие принципы

Как на самом деле работает профессиональный рост

Представьте что вы нанимаете разработчика, у которого 5 лет опыта. На вопрос о том, пишет ли он тесты к коду (любые), он говорит нет, объясняя это тем, что где-бы он ни работал, везде не было времени и возможности этим заняться. При этом он наверняка скажет, что-то в духе “а я так хотел чтобы тесты были”, просто потому что это вроде как считается правильным. Какие выводы вы для себя сделаете в этой ситуации?

Если не брать пограничные случаи, для меня это говорит об одной важной вещи. Человек перекладывает (не осознано) ответственность за свой профессиональный рост на работадателя. Он растет только если ему предоставляют такую возможность и не растет если не предоставляют. Правда люди часто не растут даже если такая возможность в компании есть, но это уже другой вопрос.

Это не проблема, когда нужен рядовой исполнитель, но в случае поиска сильного спеца или человека с прицелом на рост, такой ответ может стать красным флагом. В моей картине мира, моем собственном пути, друзей, знакомых, сотрудников, я всегда вижу одну и ту же картину. По-настоящему сильными спецами и руководителями становятся те люди, которые делают что-то не потому что им говорят делать, а потому что они понимают что такое быть профи, представляют как туда идти и целенаправленно это делают.

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

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

p.s. Поделитесь своими историями, я знаю что тут много топовых ребят)

А вы пользуетесь законами Де Моргана при преобразовании логических выражений? Если да, то откуда узнали про них? Мне интересно, как щас без универа (и наших курсов, хаха), про них узнают?